Bonus points for recognizing the bullshit parade that is the current startup world. e.g.: NodeJS has value, but it's mostly the same wheel we've had for 20+ years. Or that MongoDB's changelog has consisted of standard SQL features for the past five years and that pgsql would have been just fine (had people read some boyce-codd anyhow).
Take for example, Walmart Labs move to Node.JS + React [1]. The rationale is quite obvious here. It's a step to distance from the corporate portrayal of "Walmart" and create an image of a nimble, developer-friendly team (There maybe other important reasons, but I'd assume good PR mattered a lot). Contrary to what HN may suggest, the first thing that exhilarates a developer (the early ones to say the least) isn't the business, it's the tech.
[1]: https://blog.hellojs.org/walmart-labs-releases-electrode-mov...
So when I see a job posting advertising those I know the people in charge have no clue in what they're doing and treat developers as janitors.
Or as pg said: "The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those."
don't forget the tennis courts
I've definitely had people that interviewed well that just wanted JIRA tickets fed to them immediately upon starting. It's very hard to figure out if someone will seek out and make improvements consistently from the basis of conversations.
(I'm in ops so there's rarely a body of code available they can share for how they work, either.)
I mean, what ambitious person would like to worse in less that best job available on the market, for best possible money?
Funny, because it's pgsql that added a JSON data type in response to MongoDB and others.
* It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.
And modules in NodeJS are truly modular as they contain all their dependencies, even libraries.
The latter: as mentioned in my previous post, this is, to me, a misfeature. Transitive dependencies being encapsulated in a dependency increases the likelihood that those dependencies don't get fixed when bugs inevitably arise in those transitive dependencies. Do not want.
Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
I think I'll have to make a blog post to explain it in more detail. And I encourage you to do the same ...
What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration. Software is special as it cost very little to copy code, so your one hour contribution can be copied many times creating a lot of value. It's like you would bake one cake once and it could be eaten many times, over and over again.
Alright, I get you now. I agree with you on this that it does allow for that sort of encapsulation--but, IMO, that's a bad kind of encapsulation; having to put fundamentally object-oriented data outside of the object strikes me as a profound routing around serious linguistic damage.
> Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
This, OTOH, is pretty much the same as any language with any kind of encapsulation. Maybe ES modules have finally approached parity, but it's nothing special.
> What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
Every dependency of your dependency is transitive. Just go look in the node_modules directory of any of your dependencies! If you require X and it requires Y and Z, bugs in its version of Y or Z are suddenly your problem. And its upgrade strategy becomes your problem, too.
OTOH, in something like Maven, saying "no, use my version of this transitive dependency" is very straightforward.
> If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration.
And my client doesn't care. If I'm working on my stuff, sure, I'll do that if it's the most efficient way to solve my problems. My clients do not give a single shit about this, though, and I have to build things they can deal with, not me.
So this is at best a misfeature. Primarily a bug.
function takeScreenshot(webUrl) {
var webshot = require('webshot');
...
}
function visualDiff(imgPath1, imgPath2) {
var imageDiff = require('image-diff');
...
}Try building something with SDL on Windows if you want to see this for yourself.