Generation Javascript

Published on 30 December 2014

I’ll start by saying that this is not a rant, but rather a cry of despair that I’m repeating and that slowly – but steadily – seems to come to consciousness in our industry, like this one. The phenomenon I’m about to describe is not only limited to the Javascript community either, that community seems a lot more affected than others.

Up until this morning, I had been mumbling about those concerns mostly to myself, and to some colleagues and friends. Then I read this article and I felt like I had to do something. This really is a good read, if you haven’t seen it yet, I recommend adding it to your reading list or Instapaper or whatsonot right away. The article, A generation lost in the Bazaar, talks about Unix and how the lack of overall design or “bazaar” mentality (depicted in The Cathedral and the Bazaar) have made it extremely hard to get anything done without digging through a jungle of libraries that kind of repeat functionality, contain copy-pasted code, or depend on libraries that they perhaps don’t need at all.

Incidentally, I just come back from a trip to Morocco, and I’ve been to the Souk in Marrakesh. Some of the Souks are extremely tourist-oriented: everyone tries to sell you their stuff (which is colorful and shiny) – and every few stalls or so you find about the same things.

See, there is a dark side to the bazaar. Imagine you are a newcomer to Javascript development these days. Which librairies should you pick to get started? No, wait, which package manager should you pick to get started?

Granted, this won’t stop you from getting into Javascript. Once you have chosen which of the frameworks to go with, and after some time getting used to the quirks of the language itself, chances are that you will be productive. Or will you?

My experience has been that the super-fast code and refresh cycles make for a very gratifying experience: change something small, see the result right away. When you’re more on the pragmatic side of things, this is very useful and you can get something up and running quite quickly. There is, however, a price to pay to the approach of coding through instant gratification.


First of all, there’s the the trap of getting caught up in speed. It is one thing to get to a reasonable functionality in a short time, and another one entirely to build a piece of software that can be maintained or worked with in a team over an extended period of time. It is all too tempting to leave working code as-is, withouth refining it or improving it in a timely fashion. And before you know it, someone else has picked it up, or you yourself have picked it up again, copy-pasted it (god forbid!) or increased its complexity where there would have been a simpler solution would you have given it some more thought.

The second issue with “the speed” is that there are no natural pauses to stop and have a chance to think about the code that has just been written down frantically. Yes, interruptions are annoying and counter-productive – but I believe that correctly timed interruptions are very useful as well, because they give us programmers a chance to step away from the keyboard and use our brain for a minute. Of course, we are also using our brains while we write code – but give it enough time and practice, and much of the code or algorithms one writes down in our profession are written out of habit rather than out of carefully consideration.

Some of my best code has been “written” away from the keyboard, on a piece of paper or on a whiteboard, and only after iterating it for some time did I take the step to input it in the computer. I wish it always was like this. Much of my days are spent in front of the computer rather than away from it, even when I sense that what I’m doing is not the most productive thing there is. There is an expectation, I think, that “computer people” should sit in front of a computer. And if they don’t, it must be because they are not working. I don’t know to which extent this holds true in the creative working places à la Googleplex, but it certainly is the case in many offices around the world. The culture, it would seem, goes in favour of encouraging the production of lines of code over the production of a carefully crafted design.

Lastly, combining a quick iteration cycle with a seemingly infinite amount of libraries makes for a very dangerous mix. Everything is just one bower install oh-my-shiny-library away. The hardest thing in Javascript development today is maybe less the development itself than knowing which libraries to pick. It is very hard to tell which one will still be actively maintained a few months (or even weeks) after having added it to your project. This is where things are worse in Javascript-land than in any other community: much of the libraries out there are small experiments rather than side-projects meant to last for a bit. Yet other communities also have tools that provide the “fast reload” approach to coding, but don’t suffer from the same insane amount of libraries to pick from. Why?

Let’s go 15 years back in time. In the article that triggered me to write this entry, Poul-Henning Kamp makes the argument that the dot-com boom led many people without a formal CS education to get in and “just hack it”, and that the lack of formal education is in part at the origin of the lack of quality we see in software today. To be honest, I’m unsure about the formal education bit – I like to believe that with enough self-discipline, drive, and humility, it is possible to get good at it as well. But I would agree that the lack of perspective provided by a formal education in combination with everyone running around and screaming “just hack it” is not necessarily a recipe for success.

Fast-forward to today and to our jungle of half-dead Javscript libraries (I don’t want to call it zombie army just jet but we probably are not too far away). What happened? We are now in another bubble period with great opportunity for people in the IT industry, and we want to have as many people as possible join the party! Everyone should code. And we have made it so easy! Create a GitHub account, watch some of the many, many tutorials out there, and get going! Yay!

The sad truth is that something essential gets lost in all of this everyone-can-do-it-yay-lets-all-code euphory. I’m not exactly sure how to call it, so I’m going to pick something that is close enough to describe what I mean. I’m talking about craftsmanship. There is something to the pride of quality, the “work well done”, the “love of the craft” that is not communicated through the plethora of online courses and Learn To Code In One Week-End hackathons. This bit of pride and self-restraint is what I believe is lacking in the Javascript community. Instead of contributing to existing libraries, everyone wants to start their own and show the world that they, too, can code. It is Torvald’s “Release early and often” without the community smashing the ego of anyone publishing sub-par code.

Not everyone should code. Not every week-end project should be made public and available through Bower. The Javascript community needs to learn to filter itself. But that’s more easily said than done. There are so many people active in this community, nobody really knows whom to listen to. There is to the best of my knowledge no “Torvalds of Javascript”. Worse yet, “role models” (that can attract enough attention) such as the once very popular AngularJS framework pull a Google and declare that they’re going to be entirely backwards-incompatible with their next release, leaving thousands of developers out there wondering what tool to pick until the next release is out, and fueling and attitude wherein the well-being of the developers of a tool, not the one of the users, is most important.

I know it’s easy to critizise. But given the seemingly ever-increasing popularity of Javascript, if we don’t want to be flooded with IT job ads in 10 years time be along the lines of “Looking for Javascript developer to maintain legacy project depending on 36000 unmaintained NPM modules”, we need to do something. And the first step, perhaps, is to start by raising awareness. I hope this post will help with that.

Liked this post? Subscribe to the mailing list to get regular updates on similar topics.


  1. Thus article is excellent and very much resonates with me. In the last three months I have been getting into JavaScript development, and while I like it, there has been “something” that I couldn’t quite articulate (until reading this article) that has been bothering me. Everything does indeed seem to be moving so fast, and it’s hard as a newcomer to decide which framework to invest in. And by invest, I mean not only which one to focus on learning, but also which one to contribute to.

  2. This hits on so many great points.

    Package managers upon package managers, with the new hot frameworks that have already been built 1000x before. But we use “XYZ” now, because it’s trending on Twitter, with no regard to stability, documentation, or maintainability. So it’ll be abandoned in about 3 months and no one will know anything about it.

    The argument about craftsmanship is VERY well put. Everyone learning to code for the sake of coding is a horrible idea. When the industry becomes saturated with a bunch of inexperienced “coders” with little understanding of architecture… garbage is made. When too much garbage is made, our industry just starts to look like garbage because it’s what most people put out.

    How many times can an investor get burned putting money into a startup run by kids without enough experience before they learn their lesson?

  3. Holy Crap, you sound like a whiny crotchety old man! Why don’t you throw in a few “Get off my lawns” in there too!! Coding should be like art. No one can draw or paint right off the bat, but to become good at something you have to do not spend all day thinking about doing. I get a lot of your points between the lines of all your complaining, but holy crap man you are missing the point by a long shot.

    • No drawing or painting is being depended on to run anything important. Code increasingly is.

      Coding, maybe not necessarily Javascript, but programs run most of our financial institutions nowadays. They run our banks, they run our shipping, they run production, they even run many parts of your car.

      Do you really want any of those systems to be founded on poor code full of bugs everywhere?

      It’s already pretty bad and full of bugs everywhere when we had CS majors and actual “trained and learned” professionals building the software. Imagine if you had less trained “code artists” building those things.


    • What IS the point, then? Coding may be like an art, but its output is not. People depend on our work to get their own work done. As such, our priority should still be producing the best work possible.

  4. I have no formal CS background. I was writing code for literally years before I learned some basic design patterns, and that was after I had to learn a couple of languages, html and css, sql, some simple algorithms, typing, frameworks, object oriented programming (my first “language” was *shudders* PHP4), vcs, pointers and recursion, linux and systems administration (apache, mysql and eventually postgresql, mongodb, unicorn, mongrel, etc.), networking, load balancing, deployment, testing, continuous delivery, apis and RESTful HTTP, ruby, rails, node.js, npm, bower, grunt, gulp, tdd, pair programming, bdd, agile, scrum, etc, etc, etc, just to do my job.

    The experience required to be a functional developer takes years to learn, and STILL requires almost constant, continued education. It isn’t surprising we have a craftsmanship problem; everyone’s in a mad scramble just trying to keep the lights on as our profession continues to blaze forward at a breathtaking pace.

  5. Very nice article and it is indeed something which has caused me to drift away from things like Node.JS where it’s always a struggle to find libraries that work together, or indeed are even maintained. Back to projects like Drupal, although in an entirely different language, with a community with many set standards causing many of the modules to simply work with one another.

    Very interesting read!

  6. This article misses the entire point of javascript modules. MODULARITY. If my pet XML library dies off in the next few months, I should be able to drop in a new XML lib with minimal adjustments! Non of this phantom spaghetti code if you let package managers do their job. And if you write internally consistent source.

  7. When I ask them, students in my beginning programming classes tell me they would not build a house without a blueprint, or even try to build a bookcase without some sort of plan. Yet they try writing programs without any preliminary planning or design. I remind them that programs written at the keyboard look like it, and that is not meant as a compliment. And yes, I think the “instant turnaround”‘ does have something to do with it. Putting on my “cranky old man” hat: when I learned programming on an IBM 360 mainframe, and you had only ten runs (with one-day turnaround) to solve the problem, you did a lot of thinking before you wrote.

  8. Agree!
    This is not a problem alone with JavaScript or open source projects for that matter.

    There are a lot of companies out there that push developers to do the quick, hacky solution without thinking about the future consequences that these have.

    Luckily most of “respected” Javascript developers usually use quality assurance tools such as tests, linters and CI environments (such as Travis, etc).

    These are some solutions I propose:

    If you are an employee or an Open Source developer
    – Say no to the hacky solution and expose the obvious consequences these have for every particular case to the people who make decisions
    – Incorporate quality assurance tools to your project.
    – Learn more every day!
    – Share that knowledge

    If you are an employer
    – Usually, quick, hacky solutions are bad, get feedback from your developers!
    – Incorporate in to you development process formal stages of the Software Development process such as Requirement gathering, Analysis, Design and implementation
    – Incorporate quality assurance tools as part of your process, and understand why you want to invest time in them
    – Continually give your developers the change to learn and make them self better
    – Invest time in refactoring


  9. ‘$ bower install auto-thread-response’

    I agree with most of your points. The only remark I would disagree with is..

    ‘ There is to the best of my knowledge no “Torvalds of Javascript”. Worse yet, “role models” ‘

    I think there are a lot of influential JS developers. I’d say TJ Holowaychuk is a candidate for “Torvalds of JS” ( albeit he has moved onto GO as of late.

  10. Great work chap. I think the lack of craftsmanship really is the heart of the problem. The challenge is that an understanding of craftsmanship only comes from lots of learning. A formal education helps, but it also takes time on the job, exposure to other languages and communities, and good mentoring to become a true craftsman.

    Software is a trade, like wood working. But the difficulty in software is that it can appear to work but still be poorly written. An ugly or poorly designed chair is much more obvious.

    As you hinted, good software not only meets it’s requirements, it is extendable and maintainable, and therefore has tests and documentation.

    Bob Martin has been working hard to raise awareness of these issues. But we need more good role models. Keep waving the banner.

  11. This is a great article and also quite true there are dozens of libraries popping up ever single, single day –most of them are trying to solve a problem that we come across every day and I strongly support it.

    A good example of this is a lesser known library called ClampJs which makes line clamping a LOT easier then fussing around with CSS.

    HOWEVER, this all comes at a cost. Yes you need to learn more libraries, but here is where the magic happens. JavaScript, in my opinion, is a magical programming language whose community has decent design paradigms.

    Firstly, everything is an object and no one really does heavy object oriented programming. This makes libraries easy and quick to understand and super easy to debug because inspect objects in the browser. (especially with chrome’s auto-completion) If you’re programming in the NodeJs world tools like node-inspector make programming feel like the same experience.

    One of my fears of ES6 of introducing the Class keyword is that the language is going to be over-complicated and then we will get the verbose object oriented paradigms as seen in Java. JavaScript developers who use RequireJs or Nodejs follow the module pattern in that they try to keep things as simple and as isolated in each file as possible. (some rare exceptions) Because of the usually shallow object hierarchy and using objects more as data containers its relatively quick to learn and trace a problem in your code.

    JavaScript is becoming more and more the lingua franca of the internet. Why hire a Rails or Python developer who knows javascript and have them master multiple programming languages than have everyone master the same language and use nodejs. (which is still technically not read for production until v1.0 comes out) The benefit is that we get more tools, frameworks and libraries to harness in our arsenal. Additionally, nodejs has learned from all of its predecessors of rails and python about best practices for dependency management and version management (NVM for example) NodeJs doesnt require you to have multiple copies of the Node binary for each project you run. Dependencies are installed both at a global and local level which makes hopping from project to project a lot easier than using Virtualenv.

    Dealing with the “too many libraries” problem a while I did mention learning these libraries are incredibly easy (if you know express you can learn Hapi and Koa in an hour each) the main way to tell the worth of a framework or library is to know how many places and people are using it and what are the alternatives. Any developer worth their salt will start digging around before making a decision. (otherwise you might end up using an obscure MVC library like serenade.js) It’s less about trending, and more about having a thrivng development community that’s developed best practices for working with the framework. (there is a TL;DR about this below)

    In the article it discusses dependency managers. Npm we can assume is the defacto package manager for nodejs. there is not much of an argument for using anything else, since its great at what it does and is defaultly bundled with node. No special install instructions required.

    Frontend Package Managers on the other a hand are used to have a separation of concerns between your fronted and back end. A good example is if you have one nodejs backend serving multiple sites with their own dependencies. There are multiple package managers out there, lets take a look at them: Jam, Volo and Bower.

    Jam Package manger unknown to me until a few minutes ago. Has 1,400 stars, 93 forks and 17 contributors last commit 6 months ago.

    VoloPackage manger Has 1,050 stars, 76 forks and 11 contributors last commit 2 months ago.

    BowerPackage manger Has 11,500 stars, 1,300 forks and 129 contributors last commit 8 days ago

    Between Jam and Volo things are neck and neck, but it is clear, with minimal doubt, BowerJs is 10 times more popular and more up to date than any of the others. If you were to start working on a project today Bowerjs should be your first choice (unless there is something more popular or has proven better for your usecase)

    TL;DR: Having many libraries is great because it gives you more tools to work with than you default hammer. When choosing a library a developer should have the experience to know to look and see how popular it is, how maintained it is and if it really solves your usecase.

  12. I disagree on the “not everyone should learn how to code” part.

    Arguing that teaching everyone to code is bad for code craftmanship is like arguing that teaching everyone how to write will cause less great literature to be written.

    If we only taught people who aspired to be novelists how to write, would we be better or worse off as a society? Would we have more or fewer great novels? I’d argue the latter in both cases, and the same for programming.

    Sure, not everyone who learns to code ever masters the art, (just as some people never rise above a high-school level of writing English) but I just can’t believe that we’re not better off, both as a society in general and as programmers specifically, by increasing the average programming “literacy” rate.

    The problem is not in teaching people to code, but an inability to distinguish good code from bad. Our with our current situation, it’s as if I walked into a bookstore and To Kill A Mockingbird is on the same shelf as a bunch of high schoolers’ essays on school uniform policies. That’s a problem, but the solution isn’t “don’t teach high schoolers to write”.

  13. You are right about the insane speed at which new JavaScript libraries pop out of the ground, and the speed at which libraries can get outdated and abandoned. It’s hard to keep up with the newest technologies in JavaScript land.

    I disagree though that this is a bad thing. See it as an evolutionary ecosystem at high speed. Plenty of new initiatives, and only a small number of them, the “fittest”, survive. Until they replaced with something better again. You see young frameworks like Angular suddenly popularizing two-way data binding, making it easier than ever to integrate your UI input elements with your data models. You see even younger solutions like React coming up with a totally different approach to UI data binding, brilliant in it’s simplicity. And how about Meteor? These libraries all come up with really innovative stuff. It’s definitely not just “more of the same”. It’s a little overwhelming though that all this innovation is happening at such a high speed.

    Now, for new comers, it can indeed be hard to figure out which libraries to use. We need better solutions to filter and find libraries by their popularity, maturity, activity, etc, and filter out all these v0.0.1 experiments. But we should definitely not raise the barrier to publish these experiments: they contain innovative gems which are waiting to get discovered and embraced. Anyway, there is work to do in making it easier to find the “right” libraries.

    I don’t recognize what you say about a lack of craftsmanship in the JavaScript community. It’s more the opposite. Leaving alone all these v0.0.1 experiments, the popular JavaScript libraries tend to be of high quality, are well tested, well documented, and have an active community. It’s way better than what I’m used to in for example the Java world, where, on average, you will get a useless JavaDoc listing the method signatures and that’s about it.

    Yes, the JavaScript world is moving fast. But so is the real world around us. Remember the time that internet didn’t exist? Smartphones? How about the Internet of Things which is taking off as we speak? This may drastically change the world again in just one or two years from now. Working in an agile way is no longer optional. We must move fast to keep up with all these innovations. I hope we will get in calmer water some day, but I’m sure it will be worth it.

  14. Perhaps, but JavaScript ecosystem makes it much simpler to write clean, maintainable, well tested code. I know, it is hard to believe, but the JS is flexible enough to have a great variety of linters, testing frameworks, coverage tools, parsers, command line build tools etc.

    In the long run, I see the focus shift a lot more towards modular and well tested code, and most dependent packages in NPM registry are pretty stable and dependable.

  15. The very thought that poor software quality started with the dotCom boom then you’ve been locked in a closet smoking crack for the past 15 years. Commercial software (the Cathedral) wasn’t written with quality in mind, it was written to be profitable. Using the javascript ecosystem as a straw man for open source, which is what you’re doing with this article suggests you have no idea about the world of open source software development works.

    The tools in the javascript world are small because the applications are small. Small applications means that the sunk cost of a javascript application is small so it’s often easier, cheaper, faster and honestly better to simply rewrite rather than maintain. Don’t confuse the economic based decision of building many small throw away tools, library’s and frameworks with ignorance. Money makes our world go around and only academics can afford to ignore it.

  16. I agree with the article that there are a lot of problems with the churn of the latest-and-greatest JS libs these days. I think the true reason behind the near-continual upheaval of the process is a simple one: we don’t know what we’re doing just yet. Software Development is a very young discipline compared to nearly every other trade in the world. Whereas carpentry has had not just centuries, but millenia to iron out all the kinks and bad ideas, software development has had decades at best. I have no doubt that if you had a TARDIS and could go back and watch the first people trying to build large-scale construction projects, you would see a lot of failures as well. That’s why this churn doesn’t bother me too much. Yes it sucks to have to learn new things and then have that knowledge thrown out the window. This is why I’m still a Backbone user, well after it was in-vogue. (I’m not trying to extoll the virtues of Backbone nor flog another technology for its flaws, I’m just using it as an example.) Pick a technology and stick with it. Something better and cooler and more hip will come out. Oh well. Next product (or rewrite) use that new shit.

  17. While I can agree that having some more emphasis on the craft of coding and maybe less emphasis on releasing things. I wont agree that we need a ‘torvalds of javascript’. We don’t need a raging asshole telling people they are terrible. We don’t need someone who shits on any other coder. We need people to shepherd the newer coders in our community to teach them to value the craft as much as the creation.

    The package manager problem is extremely silly. JS is not the first time that there has been a split in package management. “easy_install pip” is a common thing in the python world. How about “gem install bundler”. Languages want platform independent ways of installing their packages, usually tailored to their needs. deb/rpm/emerge/ports/brew/msi/pkgbuild means there isn’t any standard way of installing.

    Advancements or alternatives being developed in a given ecosystem shouldn’t be shunned or discouraged either. pip was FAR BETTER than easy_install but it wasn’t 100% backwards compatible on purpose. bundler uses gem under the hood but adds a bunch of extra features (iirc). bower has a focus on front end JS that npm didn’t have for a long time, it has a place as well.

    New frameworks emerge as well. Express has plenty of flaws that justify writing a new framework. It can also be used as a library for other larger frameworks (that are more opinionated and higher level) to work from. Being afraid of releasing something because you are going up against established trends means that innovation can no longer happen.

    That said, npm could probably use better search and discoverability features. Excluding packages that have gone longer than X without a release, sorting by the number of downloads, etc etc. I’d rather try to help the folks searching for packages, than stifle the folks who feel they have an interesting idea and want to share it.

  18. This article just collects the random thoughts in my head and arranges them in an order. How true? It’s a JS jungle out there. Finding or creating your path is the craftsmanship these days.

    Good coding is a craft. No doubt. Hope everyone would learn that. I think it should say “Everyone should code good”.

  19. As much as I agree with a lot of the points you’ve mentioned above, I feel the need to point out something: I’m really happy with the number of options out there, the huge amount of work the community has been doing recently, even though it may feel like that we could get better at focussing our efforts. I still see value in publishing code and making tools available to all of us, however I agree with you that there has been an overhelming number of different tools with a lot of overlapping functionality lately and for people who want to make use of them, chosing a potentially good candidate is not always easy. I believe this is the real problem and not the huge number of options out there.

    I think key towards success depends on the ability to chose the right tool for the job is in fact a skill that people develop over time and the community needs to facilitate this. Finding a tool based on functionality/category (package manager, polyfill, test runner, etc) should be made easy where one could inspect the available options out there. Being able to quickly evaluate the state of a tool based on indicators towards popularity, usage, the number of issues reported and recent activity, and probably most importantly test coverage IS in fact something that you can do already today. Code is open source so you can have a look at it before you decide to make use of it in your projects.

    Despite all that I agree that we should favour contributions to existing projects over creating our own tools (as long there’s no fundamental difference in approaches). Problem is, contributing is not always as easy as it probably should be because code can be sometimes difficult to understand and at times it’s not even guaranteed to work. (Admittedly this is becoming less and less of a problem as testing is getting more popular across the JS community so that we can validate functionality.)

    JavaScript was designed in 10 days and yes, it has quircks, some are perhaps bigger than others. For a long time it has been considered as a *toy language*, that now we see maturing. On top of this, the arrival of nodejs suddenly JS has become a key player in 2 architectually different areas and this makes things even more complex. Things are changing really fast in this space and we need to give the community some time to adjust, to create sensible conventions and standards that we can all build upon. Think of today as JavaScript’s transition period, before we start to settle down for de facto tools and standards.

  20. I agree with all that has been written. I also agree with the cited ACM “bazaar” article.

    During interviews, I ask candidates whether they know pure JavaScript or JavaScript frameworks. 9 times out of 10, they claim to know JavaScript but fail basic questions. When prompted for an explanation, they say that they do basic JavaScript and rely on frameworks for the rest. With candidates applying for junior posts, I would just carry on with questions on their favourite JavaScript frameworks, but with those aspiring to senior roles, I nullify their JavaScript skills downright.

  21. Great article. Are you a Java developer? Because I hear these kind of complaints a lot in my company from Java developers.

    Anyway, I think you are pretty much right about the current state of the JS community. But then: If you go back 1o years in time, choosing Java libs wasn’t easy either, and I can remember the arguments with fellow Java devs back then whether Spring was the right thing.

    Alas, I think you are describing symptoms that are signs of innovation *and* immaturity. And time will tell whether JavaScript will become as grown up and boring as Java is today.

    Just saying.

  22. The article covers not only JavaScript actually. I think your opinions are also for any language community that coders and packages erupt firmly without ‘filtering’, although I suspect whether it is possible to provide a high quality package ecosystem including development and publishing from any explicit efforts and facilities, rather than programmer’s internal training. I believe for Python, Perl, Java, Haskell and other languages, or even Docker, the container platform which has an open Docker registry, the problem is still a problem, too. The only difference is for JavaScript people are too used to adopt and invent frameworks and libraries, while one of the reasons is that the native APIs are so creepy and compatibility is so necessary, so it push people immediately invent or adopt new tools to do their jobs. However, I think the deeper reason is front-end works are deviled works since it looks so easy that everyone can take it without thinking, but only when things get totally messy people realize their efforts to no matter learning or thinking, are so poor that they now can only stokpiles workarounds upon workarounds, and then (totally unreasonably but sadly it’s so common) to blame that JavaScript is too suck to write their “large” “applications”. Yes, the language has its own problems that lots of them could be solved after ES6 (stuck on nontechnical issues just like Python 3 or Perl 6), but I don’t believe the arragonce toward front-end work would disappear with other languages, so that the issues the article mentioned would continue.

  23. There’s no doubt that npm lacks adequate tools to surface good modules. You can check the stars and downloads level, of course.

    However, why should npm go beyond simply managing packages, to trying to make opinionated decisions for you? That violates the principle that you should do one thing and do it well.

    Node is not Python. Python has a huge standard library covering a lot of use cases. But it is one-size-fits-all, and you may not like the implementation. Or, if you realize that it is slow and that a non-blocking methodology is what you need for your webserver, suddenly you have huge amounts of code to replace.

    NPM encourages contributions and is much larger, but you don’t know how well the code is executed. That is a deliberate choice in philosophy, though.


    Ways to find good modules

    * Find a module on one of the following sites:
    * Ask the Node mailing list or IRC.
    * Better, search the mailing list to see if your specs for a module have been discussed before.
    * Look for stars on NPM or Github
    * Search Google for “nodejs authentication module” or whatever.
    * Search a secondary site, such as Hacker News or
    * Ask node people on twitter which modules they use. Or, better, ask the relevant Google+ communities.
    * Go to a meetup or node conference and find out what other people are using.


    Micromodule Philosophy

    One reason that NPM works as well as it does, despite the hordes of “zombie modules,” is the micromodule / microservice philosophy.

    Node is built from the ground up with the expectation that you develop mini programs that do as little as possible. E.g., it is preferred for a module to export a single function. A great many modules are less than 100 lines long.

    This means each microtool can comptently satisfy a very specific purpose. The purpose is small, so you can ideally evaluate the module a lot easier, and the module will ideally require less frequent updates. If you hit a troublesome module, you can probably find a replacement without too much work. You hit problems when you have huge modules or when you have too strong of a coupling.

    As long as Node doesn’t change their API, your microtool will stay relevant. This is why backwards compatibility is so important in the core Node modules. Many of them are fixed now, and they hardly ever break compatibility. When it hits 1.0 (which they are taking their sweet time, no kidding), they basically promise that all their APIs are fixed, so they won’t ever break backwards compatibility with anything, ever again. Sort of like the way that Intel x86 CPUs refuse to break backwards compatibility.

  24. There are many truths in what you said.

    A possible solution could be to use those languages that make reflection a necessity because they force you to go to the whiteboard before even trying to code even the simplest thing.

    I am talking about these languages à la Haskell that pushes you to model your domain beforehand through types and then allows you to move only within this model, with the rules that you defined.

    I am saying this because currently I am learning both Haskell and also Purescript… And, really, it is the opposite of what you described – maybe too much.

    But Probably this approach might mitigate some of the problems you’re highlighting.

    Happy new year!

  25. Call me old-fashioned if you like (and it would be fair comment), but …

    I’ve been programming JS for 15 years, I still don’t know what NPM is, I’d never heard of Bower until I read this article. Each new project, for me, consists of an empty page and a text-editor. The standing assumption is no libraries or external dependencies of any kind, and that changes only as and when the project requires it.

    It seems to me that the root of the problem you’re describing is the “library culture” — the assumption that you always need 3rd party libraries to do anything with JS. But you don’t. You can write your own abstractions that are tailored to the demands of the application, and the result is almost always more efficient — smaller file-size, faster execution, less memory consumption.

    Not that I’m criticising the concept of libraries — if you need one, then use it. If you can write your own, even better. Nobody wants to be re-writing the same functionality in every project.

    But I think the industry would be a lot less intimidating to new coders, if they didn’t feel compelled to navigate the minefield of libraries that now exist, before they can do anything. You can build useful functionality with nothing but a text editor and a browser.

  26. I got the idea between the lines and I must agree. This whole bunch of new things and the insane desire to create something innovative and new to show the world have become insane. This article reminds me of that bullshit of “ninja”, “rockstar” and the disgusting words people like to proclaim – those things that just deviate the beginners. That tweet you mentioned resume the article, it’s tiresome. To make the JavaScript community stronger, the environment as whole must become mature and I believe one of the best ways to do this is – creating a better and effective way to learn the craftsmanship, professionally. For the comments I read, the article sound retrograde for some people. Thanks for the words!

  27. I’m curious what the alternative looks like. In your opinion, is there a langauge/platform/community that Gets It Right?
    Throwing UNIX out as an another example of this “problem” hardly makes the case, considering UNIX Is one of the most successful platforms ever.

    To me, the rapid change and evolution makes JS exciting to work in. The alternative seems like stagnation.

  28. Personally I don’t think having multiple libraries doing the same thing is the problem. If you look at any language C, C++, Java, PHP, JS, C#, etc. there is nearly always multiple libraries that do roughly the same thing.

    The difference to using package managers is when you want a library you ask Google and/or other developers which immediately sorts the projects by popularity and filters out all the ones where the creator(s) lost interest.

    It’s sort of like survival of the fittest but for libraries. The maintained libraries get promoted by their maintainers, well written ones tend to gain more users, etc. which naturally filters out the dead or badly written ones.

    Another thing not using a package manager does, is make it much more painful to use a 3rd party library which helps reduce them to only the bare minimum.

    I agree with your point about depending on 1000 unmaintained libraries, however no piece of software should ever depend on 1000’s of libraries in the first place. If it does then it’s either badly designed or it’s doing too much and should be split into multiple chunks itself. Yes, it will still indirectly depend on the libraries but it reduces the cognitive load to maintain and, more importantly, helps isolate any unmaintained libraries so that replacing them becomes much easier.

    P.S. I disagree with the formal education part, out of all the developers I’ve worked with the thing that made the biggest difference between good and bad was their interest/passion. Someone with an interest that keeps learning and improving will always end up better than someone with the best education and no interest, especially in such a rapidly evolving field.

    I agree with learning to code in a week though. There is a lot more to programming than just the basic syntax.

  29. My experience has been that recent CS graduates (esp. those without any experience with JS/prototypal languages/functional programming) are the most difficult to train in modern web-based application development techniques. The reason is probably that CS has pretty much nothing to do software product development. And those who understand how to develop products are the ones in demand. The rest is being commoditized.

    So I would suggest that you’ve missed the point. Programmers are no longer the ones designing software. Skilled product designers/architects can reduce applications into distinct, well defined, isolated pieces and reduce the weighting of programmer skill via this isolation. The jobs where (highly) skilled developers are needed are decreasing, and the number of those jobs is increasing.

    I would be surprised if anyone would argue with the claim that over time programming has become easier. That is, the amount of knowledge needed to bind an interactive, multi-user client interface to an easily scalable database, for example, is not increasing, but decreasing. Indeed, building such a thing is nearly “pushbutton” nowadays. This is because many (actual) CS types have been working to create languages, databases, protocols and other tools that are simultaneously more powerful and easier to use.

    CS has been very successful, not less successful. CS advances = more accessibility for less “skilled” people. We are much better at building maintainable software now. We build much more scalable, more resilient systems now. And we employ less expensive, and less expensively trained, citizens to do that.

    Software is winning, IOW. Not losing. And more people have jobs because of that. All good things.

  30. > ‘There is something to the pride of quality, the “work well done”, the “love of the craft” that is not communicated through the plethora of online courses and Learn To Code In One Week-End hackathons.’

    This is just wrong, and I’d be too nice if I didn’t say it’s a bit condescending, too. I learned to code when I was learning to read and write English as a child. If a young child can learn to code, anybody can learn to code. I’ll add that the problem solving, math, and logic I learned programming as a child helped me understand _everything else_ better, including reading, writing, and arithmetic.

    Thinking that the ability to read, write, and understand code should be a camp reserved only for the elite is quite opposite to my own observations (not opinion — observations of real life) as both a student and teacher of programming.

    Today’s newbies are tomorrow’s leaders. Treat them with welcoming respect, please.

  31. I enjoyed this article and comments and I’m currently working as an AngularJS developer on a very large enterprise project and I have a few thoughts.
    AngularJS is leading edge so you rely on the community quite a bit and abandoned and unfinished project abound. Sometimes it’s annoying and sometimes you get exactly what you want. It’s just part of the job and it’s been that way since people started sharing their punch cards.
    And those kids right out of college? I work with some of the top computer talent coming out of New York City universities and they all come equipped with plenty of Java, Python and math skills but that’s not helping them much when they are tasked to write D3 or AngularJS code. They are in the same boat as everyone else learning things as they go along, testing projects, sharing code, grokking things out.
    My AngularJS code has to talk to a Spring back end and as a Node.js programmer tasked to maintain a Spring application on my development box I will not shed any tears when Java is put out to pasture. Javascript won the browser war and it’s about to win the web server war and take the enterprise.
    Enterprise is just about to go crazy with mobile and the need to quickly launch hybrid enterprise apps is going to drive people to a pure stack where the get more bang for the buck—the Javascript stack.

  32. Some interesting thoughts but I can’t say I agree with most of it.

    The high quantity of code of JS code being unleashed on the world is a symptom of a healthy and flourishing community. It’s OK to have 10 different modules by 10 different people that do the exact same thing. People learn by writing something for themselves – it doesn’t have to be completely novel in order to have value.

    And as for your parting shot at Google over angular, let me just say this: I will HAPPILY learn a new version of angular in order to move the framework forward instead of being anchored down by legacy design decisions. While some other devs are wailing and knashing their teeth over having to learn something new I will gladly do it and I will do it over and over again as the next iteration comes down the pipeline. With change comes opportunity and while other devs are crying I will be eating their lunch.

  33. I agree with most of this post. Most.

    I agree that haphazardly adding multiple NPM modules and the like to a project is a problem. A problem I have been bitten by, both in my own code and in code I was asked to maintain.

    I disagree, however, that the flood of “JavaScript” packages is a bad thing. What we end up with is choice, opinions, and different ways to solve the same problem. None of which I consider a bad thing.

    Sure, it’s a bad idea to include “Joe Rockin’ Coder XML Parser” in your enterprise level web application, but at the same time, it’s nice to have the option.

  34. While it might be arguable that Crockford is the Torvalds of Javascript, that’s beside the point.
    I agree that it is probably not the lack of formal CS education that is a root cause of Javascript’s “package problem”, however, there is something interesting that comes with that approach, especially in OO-centric education, which most programmes follow. It’s namely the idea of the “black-box” API, right? Pay-no-heed to the internal workings of the intricate engine, just drive the car so to speak. While a disciplined programmer will apply that practice with prejudice, the trickle down effect of that practice to the learning, unconsciously incompetent, or simply lazy programmer leads to many a copy-paste, and at a large scale, bower install oh-my-shiny-library

  35. […] A great example of why developers need to refactor – Manuel Bernhardt “It is one thing to get to a reasonable functionality in a short time, and another one entirely to build a piece of software that can be maintained or worked with in a team over an extended period of time. It is all too tempting to leave working code as-is, without refining it or improving it in a timely fashion. And before you know it, someone else has picked it up, or you yourself have picked it up again, copy-pasted it (god forbid!) or increased its complexity where there would have been a simpler solution would you have given it some more thought.” […]

  36. “…I believe that correctly timed interruptions are very useful as well, because they give us programmers a chance to step away from the keyboard and use our brain for a minute.”

    This is a very good comment. I have been trying to change the perception about unit testing for this very reason. I think the idea of get-it-working is a necessary first step and doing so gives you the knowledge and experience with the code to then go back and make it better. The then go back part is usually never done and from what I’ve seen it’s not for lack of time, but because it’s very hard work and most don’t want to face it. It’s much easier to put blinders on and build bad code that works than to make bad code better.

Leave a Reply