1) I saw the presentation, there was more info. These are just the slides.
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.
And expressing negative biases seems to be very common in the HN world. Say what you will about JS, I didn't see a single person being rude or dismissive towards another person during this conference.
Always being PC isn't a good thing. I see tech people being too nice to sales people, and a lot of those people aren't really interested in being a genuine friend. It's time that real developers in the tech industry decide to actually be passionate and support what they care about. Not about what some sales presentation tells you to care about while giving you mediocre freebies to make you feel like you should "trust" them.
After the Nth time in which npm failed to install correctly (incorrect package resolution and even an occasional stack overflow exception) we moved to yarn and never looked back.
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.
NPM and Yarn have made a nightmare out of our project. We have 50 direct dependencies. The lockfiles only lock your direct dependencies, any transitive ones can change at any moment, making our CI builds fail when something works locally. And they don't actually check integrity -- that v1.5.0 of ABC is the same as v1.5.0 from a month ago.
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.
Yeah, I know, but we still have CI builds fail that work locally -- until you rm -rf node_modules and install again using the lockfile. The recent addition of hashing seems to be in response to my issues -- I am trying that out now.
NPM does not, but GitHub, yarnpkg?, and whatever else may. NPM does allow unpublishing a package altogether, and then you can publish again (AFAIK) with the same version.
The key things that got my team to switch to Yarn were (a) the lockfiles didn't keep changing formats when running installs and (b) workspaces for monorepos.
I'm a bit of a outsider looking in being a manager that doesn't code much anymore but why the dislike of Typescript? I really don't see the downside. Transpiling doesn't make it 1:1 anymore but all devs seem to praise it.
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.
The people who built and maintain it refer to 1.x as Angularjs, and >2 as Angular. I do agree it’s silly semantics, but google does treat them as different, the community treats them as different, they are different in all terms.
He mentioned how many angry emails he gets from angular people when he did the presentation. He's not saying its less popular, all he's doing is showing the numbers npm has.
I totally agree it’s less popular and laughed when it showed the slide saying that. But saying it is in decline is wrong even by the graph, angular 2 is increasing and angular 1 is decreasing. So maybe because not all angular 1 sites are switching to angular 2 it’s a decline?
I understand that Angular as we know it today is basically a total re-do of AngularJS (v1), but I'm curious, how is it misleading to group them together when comparing to other frameworks?
New Angular is more like Vue than it is like AngularJS (v1). Old AngularJS and Angular 2+ are very, very different. For that reason, many popular AngularJS (v1) apps have not yet updated (and probably never will without a total rewrite).
So, if a lot of the Angular decline is due to people migrating off of v1, and v2 isn't gaining in popularity as fast, is it really misleading to say that Angular is in decline? To me it seems that tons of Angular 1/2+ users are adopting Vue instead.
I was just answering the question of why it is misleading to group them together.
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.
Using Javascript is getting a bit better thanks to the latest ECMA spec. We finally have a universal module system which is designed to work both on the server and on the client.A package manager that takes advantage of ES modules is needed though, so not NPM.
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.
I know it's fashionable and popular to hate on JS. No matter what your objections are, if you are frightened of it, you should be scared. It's running in almost any modern device you own, and a decent chunk of services serving those devices. Even everybody decides to switch to WASM/Go/Python and leave JS in the dust, it'll still zombie on for a good long time. See: PHP.
> I know it's fashionable and popular to hate on JS.
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.
It was always hated from my experience. It was a flawed language designed in 3 days. There's more people who love it now then before. It's mostly from beginners who learn it at bootcamp as their first/only language.
I know Java, Erlang, C/C++, Ruby, Python, Javascript, have dabbled in Scala, Haskell, PHP, Perl, and Racket. Of these, Javascript was actually the last I learned and used professionally.
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.
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.
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.
What’s difficult isn’t the DOM itself, it’s that you thread in and out of the DOM with a changing DOM state and with multiple people writing application code. Many of the frameworks / packagers exist to help tame the context switching, since in frontend land you might have business logic that is dependent on a CSS class that may or may not be present at any given moment and might be modified by some other piece of logic.
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.
Yep. In any shared development context (or even solo but trying to ensure proper containment of component structure, logic, and design rather than just one ugly hodgepodge), there is no good solution without a framework. And because literally everyone runs into that problem, everyone has created their own framework, which is why there's so many of them.
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).
It's not my first language, I've been an engineer for 20 years, I've picked it up in the last 5. I can see what accounts for its success, it's responsive and fluid, both in its features and in its evolution which makes it perfect for what the web and emergent technologies need right now. And it's ubiquitous. It won't be important forever, but it is definitely important now.
I feel like there was a period after jQuery came along and before Node and the entire morass of "enterprise" javascript when it wasn't hated so much.
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.
Yes, it's a quite bubble unfortunately. I'm a JavaScript programmer (for the most part) and most JS devs are dumbfounded (!!) when I tell them about how Python is probably more popular than JS [1][2].
These are flawed methods of ascertaining relative language popularity, mostly relying on inaccurate searches of google and social media. I honestly don't think they're worth anything.
Popularity can be measured many ways. IEEE is way more insular than the JS community. IEEE members are much more likely to be dealing with lower-level code and/or statistical analysis. JS isn't low-level and doesn't have a very good statistical analysis suite. In contrast, with Python, you use numpy with C/C++ to do most of your work in that area. Are there more people writing that kind of code or more people wiring together consumer-facing stuff? Obviously the latter.
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.
How do you define popularity? Nearly every web page in the world is running JavaScript. Surely there are more JS developers than Python developers. Or does popularity in this case mean what it meant in high school?
It's false, because "most important" is unqaulafiable. In the browser it is most definitely the most important language, but in other areas most definitely not.
JavaScript appears to have been primarily created to spy on users. I don't need every website to take over the presentation of content. Information shouldn't be coupled with design to limit choice. I'm ready for a new browser that uses a more modern markup format.
You've been breaking the guidelines a lot, but we'd like to hear what you have to say that isn't a flippant and vacuous dismissal, so could you please read start following them?
I think its fairly well known that there are flaws in Javascript which was designed in a week and hows its used (DOM etc). The ease of its use probably lended to initial success, but the difficulty of making complex secure software has led people to reinvent the wheel it seems every 6 months.
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...
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