1. 12
  1.  

  2. 6

    I’ve personally found that the bigger issue I have with Javascript’s tooling is the fact that there are too many competing tools and approaches. That coupled with the speed at which projects seem to start, develop and die, I feel utterly lost in the ecosystem. I don’t think having an optimizing compiler would really help Javascript at this point. Many developers are more than content with sending down whatever sized bundle over the wire. In my opinion, Javascript needs to calm whatever storm its been having since node.js came out and start to focus on building for the long haul.

    1. 3

      That’s because the tools are rarely good because the developers of them are just as quick to abandon them for the next cool toolset. Good takes time. They may be interesting or an evolution over previous tools but they rarely maintain momentum to pass the growth stage. It’s funny how many times the same stuff has to get reimplemented for each new tool. How much time is wasted? Just look at house many -sass plugins there are for the thousands of static site generators or other tools.

    2. 1

      Interesting complaint. Also interesting how it essentially is taking aim at having an optimizing compiler (and praises webpack for it) and how the community could better organize to give the best information to such an optimizing compiler. I wonder what it’d be like if the Node community better embraced Closure.