NPM and the future of JavaScript
slides.com
slides.com
1) “npm is the best at x, y, z” with no data to back the assertion or attempt to address the many counter arguments
2) we just released a bunch of brand new security code! So it must be secure!
3) everyone is using npm, that must mean it’s the best, and not that technical debt is forcing the choice on everyone
4) everybody in the audience stand up and sit down when I say
Jeez
2) he went over the specific security features. They really are improving things. NPM 6 has a bunch of very reasonable new security features.
3) he never said they were the best. He was actually fairly down to earth. He attributed npms speed increase to code sharing and working together with other package managers.
4) this was to keep everyone awake after 20 minutes of charts. It was a gag.
It really was a good presentation. Hopefully the video is publically available at some point.
It's amazing to me that npm, which has been around for quite a while, still manages to be so broken. I normally try to give developers the benefit of the doubt, but i really believe the frontend world is worse off because of npm.
I saw Yarn added last month a hash of the (hopefully) source of the dependencies -- that's what we need.
Despite using lockfiles, some transitive dependency changed and we decided it was best to upgrade the direct dependency, requiring a big refactor. The alternative was to fork the library and maintain it ourselves -- which I am refusing to do from this point on. We have about 10 forked 3rd party libraries. No more.
I feel like I spend 30% of my time just trying to upgrade/maintain the current builds because some stupid loosely semver'd dependency changes, rather than writing new features.
What???
[1] transpile is also a stupid word. It's a compiler, at least as much as javac is, or ghc when it used to spit out C code that then went through gcc.
The frameworks are radically different and the install base is likely very different as well. If AngularJS (v1) was growing in popularity it wouldn’t really tell you anything about Angular (v2+), in the same way that the fact that Ember seeing a slow and steady growth doesn’t tell you anything about Angular (v2+). They’re different frameworks with dramatically different conventions and install bases. If AngularJS AND Angular were both losing popularity, it would still be misleading to group them together as “Angular.” They’re just not the same thing.
Choosing to name the newer framework was, in retrospect, an extremely poor choice, especially since it alienated all AngularJS users since there was no good migration path at the time and everything was so different; it might have made some sort of marketing sense in the pre-React/Vue world that Angular (v2+) began its life in.
There's a library that has X number of users. The library authors release v2 of that library, and it's a total rewrite. If every single user of v1 adopted v2, then you'd still have X number of users (grouped together across v1 and v2). However, you now have X minus Y users across both -- which means that some users stopped using v1 and didn't start using v2.
Which means that the adoption of your library has gone down. Or, put another way, is in decline.
Now, you could make the case that Angular 1 and Angular 2 are totally different frameworks that don't have anything in common and so they should have their adoption metrics treated differently, but even Google doesn't make that distinction, since they call them both "Angular". So to say Angular usage has gone down is factually correct, according to the definition of "Angular" provided by the people who built and maintain Angular itself.
To argue that the conclusion is wrong because the definitions are wrong (read: not the same as the definitions you personally use) is kinda just playing semantic games.
Either that statement is false, in which case the JS community really is that insular and arrogant -- or it's true, which is probably even worse.
Either way, this assertion scares me.
[1]: https://spectrum.ieee.org/at-work/innovation/the-2018-top-pr...
[2]: https://www.economist.com/graphic-detail/2018/07/26/python-i...
Likewise, the number of people searching for "Javascript" is meaningless for several reasons. There are loads of searches that would use other names like "JS" or "React" or "HTML File API" that should count, but don't and aren't easily added to that metric. In addition, there isn't much need to google for JS itself. The best sources to learn JS are free and once you find them, you don't need to continue searching. JS is a much simpler language with a smaller builtin library than Java, so even a junior dev with a few months of experience will do far less googling about the language than a similar junior Java dev. In addition, the Java dev will be googling "Java X builtin" while the JS dev will be googling "Lodash X" instead. Search result aren't great resources for that kind of analysis.
It's not an illusion that JS is popular. Applescript moving to JS. VBscript moving to JS. Qt, GTK, and others baking in first-class support for JS (complete with JS engines). Duktape, Jerryscript, or XS7 in the microcontroller and embedded scripting space. Even things like PDF have JS baked into them. Then there's web-apps, react-native apps, electron, node, etc.
If you look at the computers in someone's house, there's a very good chance they don't have Python anywhere. There's even a decent chance that they don't have Java installed (and an even better one that they have Java from years ago if they do). You won't find even one of them that doesn't have JS being used every day. If that's not popularity, I don't know what could be.
I've been in the industry for almost 20 years now. I do not remember a time when it wasn't popular to hate JS. If it's a fashion, it's a fashion that literally crossed millennia.
I like Javascript. I hate DOM manipulations in the browser, and browser based differences, but Node on the backend is generally a pleasure to work with, and far, -far- better than most of the languages and ecosystems I've had to deal with. I prefer Erlang (well, and Elixir) for larger projects with complex concurrency/distribution/fault tolerance requirements.
Yes, Javascript was always hated. It certainly has some WTF elements to it that deserve some hatred. But for a straightforward, easy to learn, get things done language that doesn't lead to a lot of bloat, doesn't force you to be concerned with things you shouldn't have to be concerned with, etc, it's actually pretty solid, and I suspect a lot of the hatred has to do with the argh of the browser, in which no language will help you.
What exactly is so difficult about DOM manipulation? I honestly don't get why people see it as a problem that warrants zillion badly written frameworks, while other critical language issues are pretty much ignored.
Everything in the DOM is basically a global variable, and any part of the app might manipulate any part of the DOM.
Example: Someone wrote CSS that is coupled to a child element (which seemed the clearest way to write it at the time) and someone else comes along to edit the content of the HTML which adds a layer and now your logic is broken even if the CSS still looks right. The frameworks make it easier to avoid that kind of fragile coupling / enforce a consistent way to manage the interaction of JS, CSS, and HTML.
All that said, web applications really are an entirely different beast than websites, even if they exist on a spectrum.
But none of that is an issue on the backend, where there's no DOM considerations. No HTML or CSS either. Just Javascript. And there it's straightforward, succinct, and usually easily understood (usual caveat of bad developers, but compare average Node codebases with average Java codebases).
The DOM isn't a language issue, it's an API issue. That issue has gotten much better in recent times, but jQuery became popular because those API issues were so big. Today, you look at caniuse and see that almost every new feature is not implemented or partially implemented by at least one browser.
That's bad when talking about something like the File API, but that used to be the case for DOM primitive operations. Instead of one browser, every browser implemented almost every feature in an incompatible way. For example sizzle (the selector that's the foundation of jQuery) came into existence because there wasn't a unified way to do something as simple as selecting a node from the DOM.
Things like querySelectorAll have made life easier for most of us, but the DOM is still a maze of barely compatible implementations. I don't dislike it to the degree I used to, but I still don't like it.
Now, all of you, get off my lawn!
The problem with javascript isn't that it's a terrible language per se - it's perfectly adequate for its actual, intended use case (lightweight scripting and DOM access.) The problem is that "flawed language designed in 3 days" is now being used everywhere, and that its ecosystem is a trainwreck of unnecessary complexity tied to a badly designed package manager linked to a proprietary backend.
I am
Second, static analysis tools like Typescript compiler or Flow can help greatly with typing with little setup or configuration needed. For instance I use Typescript compiler with js files directly in VSCode. Finally linters can help avoid common mistakes. The experience is certainly better than 10 years ago thanks to all the new tools and specs at the developer's disposal.
Disclaimer, I like TypeScript
To paraphrase the last 8th of the presentation:
- Use React.
- If we all just use React, React will live forever.
- React is better because users.
So much of the rhetoric around React is disturbingly cultish.
I don't think having a polluted and bloated ecosystem like NPM is a mark of a success of quality. Just look at what happened when someone deleted their project from NPM - they broke the internet...
https://qz.com/646467/how-one-programmer-broke-the-internet-...