Hacker News Reader

Comment by monkmartinez | Hacker News Reader

I started programming in JS then moved to Python. It seems like JS has become very, very complicated. I look at his post and I am lost... I remember Knockout.js and Node in the v0.8 days.

I mean look at this:

  dotenv (lets you load the environment from an .env file), axios 
  (HTTP client library), cheerio (HTML parsing library), bcrypt 
  (password hashing), co-body (HTTP body parser), co-busboy (HTTP 
  multipart parser), jsonwebtoken (JWT generator), koa-jwt (JWT 
  middleware), koa-router, koa-sslify, vue-no-ssr and source-map.

What the hell is all that? I am not saying he is wrong... I am just saying that I don't have the capacity to play in that playground. I am also asking if any of those libraries will be around in a year?

View on HN

I have been in your position about a year ago. The approached that helped me, was to not worry about all this.

Just start somewhere; and in a month or two, you would mostly know which libraries you need to add to your project.

The best way to go about it, is to check a few popular open source projects; what libraries they typically use.

> I am also asking if any of those libraries will be around in a year?

You can check the download stats of these in https://npmjs.com, and activity on the GitHub repo, before adding it to your project.

If they are still around, but have published a new major version to update a few APIs; you can slowly migrate to it.

If not, you'd read some Medium post or Hackernews discussion, about what is replacing that.

There's something called Greenkeeper (https://greenkeeper.io/) that integrates a GitHub bot to your repo, and files a PR when something needs to be upgraded.

You can implement something similar on your own, if you aren't interested in using something like this.

I mean no offense, but the "just use it you'll get used to it" strategy seems the antithesis of the goal of engineering as a discipline.

A materials engineer simply cannot afford to pick concrete unless she knows the specific load and weathering characteristics of it. The same should be true for software projects. You shouldn't use cheerio because everyone uses it in their project, but because you've looked through the source and considered all your options for need it fills.

Sorry for the rant, but I think it's important to encourage software developers to think before they code.

It's important to not disregard the expertise of a fellow developer before you have decisive proof that their approach is genuinely poorly thought out. That is to say: Give people the benefit of the doubt.

As an outsider the big amount of dependencies look daunting, but the tendency in JavaScript as of late has been to use small libraries that do one thing, do it well, and play well together with others (Composable is the buzzword). Whereas Java and C# for instance tend to have macro libs that "Have it all bundled in".

It's different approaches, and you might not _need_ absolutely everything, then again you might, and you are in a much worse position to evaluate that as an outsider than the developer who made it.

All in all, I quite like the JavaScript approach where pieces are just that, instead of a pre-built lego set which I'll have to study to build, I have small pieces which give me more flexibility to take my project where I want to take it. The tradeoff, and they naturally exist, is that dependency maintenance is substantially more difficult, and the likelihood of something you use being straight up abandoned raises for each dependency you add. Which might lead to having you either maintain that piece yourself, or abandon it, and add another piece that fulfills a similar role.

If you're building in cement, you need to know the cement is strong enough. If you're building in tofu, choosing extra firm over silken isn't really going to help.

Most of the Js libs are super tiny. You integrate them, learn what you need to learn in less than 10min. Each is like learning a numpy operation :). It has its benefits and problems, but it's for the better imo.

Koa has been here since 2013 (and some of those other libraries even longer). It is here to stay.

Do you see ancient but popular PHP frameworks going unmaintained and reach the point where they collect a significant amount of bugs and vulnerabilities? Not really...

Apparently it's just the guy's routine JS rig, not any sort of new standard you would have to follow or even care about.

> What the hell is all that?

Libraries of code.

> I am not saying he is wrong...

Good, because they are right.

> I am just saying that I don't have the capacity to play in that playground

Good, because you are right.

> I am also asking if any of those libraries will be around in a year?

Yes. Some have been around for years already.

Listen, it's fine that you are using Python. It's fine that the OP is using JavaScript. It doesn't make you wrong. It doesn't make them wrong. Just because you are confused doesn't make it wrong. Hell, Python should worry about itself; it has enough warts of it's own it doesn't need people pretending that a library like bcrypt is confusing.

I suspect you are being downvoted for presuming to know what the parent's capacity is.

Reply on news.ycombinator.com