That, and nose.js developers seem to repeat the claim that node.js makes delivery faster… but is it really any faster than ASP.NET, Rails, Django, or Go stdlib? Those frameworks are so fast for prototyping and delivering bread-and-butter apps as it is (and some of them let you do multithreading to boot).
I'm also really not interested in how things work for "typical CRUD apps" because those are so trivial to write in any decent environment.
I'm worried that node.js articles are the same kind of echo chamber that Rails articles were 10 ago.
Take the case of Node and JavaScript itself. The ecosystem is huge. The tooling is complex. A newbie starting out will not even be able to get many examples to run without a mesh of transpilers and build tools. There are roadblocks everywhere; what's the type annotation there? What's with the strange JSX syntax? What's a transpiler? Add to that, EcmaScript itself is a moving target, more so than any other language.
Similar issues exist in other languages. C# is a simple language to master, .Net is a huge ecosystem. There's not going to be a lot of resistance moving from C# to F#. But for the newbie, the challenges are daunting. Should you use Microsoft's preferred ORM which ships with .Net or write your own SQL? Which UI tooling should I use? There is plenty of advice on the web, yet it needs an experienced developer to make those decisions.
Consider this. if you chose SilverLight a few years back, your product is soup today.
Picking an ecosystem is not easy. Has never been.
The amazing part about JS is that most of the code written for browsers a decade ago still works today. It is extremely unlikely that we will see a company outright ban JS in their web browsers in the same way that iDevices don't support flash.
I tend to agree.
> That, and nose.js developers seem to repeat the claim that node.js makes delivery faster…
The qualification was "if your team already knows JavaScript". OK... If the team already knows Java... building something like this in Java would be faster to deliver, and wouldn't hit some of those issues the author brought up (4 vs 1, single vs threaded, etc).
And the whole "oh, you know language X" - means almost nothing when the project is more than trivial hello world. Every project I've been brought in on, the qualifier was "must know tech X". And almost always (there were exceptions) I knew more about tech X and software dev in general than the original developers, and the crunch was not "how do I do XYZ in this tech?" it was "how do I get the other developers to actually use version control?" or "use version control sanely?" or "document anything?" or "write tests" or "have test data" or "have a repeatable build process"?
Knowing ASP or PHP or Ruby or whatever, but going in to a project without repeatable build process, tests, documentation, requirements or version control, is a recipe for disaster. Stressing the "deliver quickly" aspect of any language, if you're actually trying to deliver for a business or with a team of people, is extremely destructive short term thinking. And yes, sometimes, in rare cases, it may be a necessary evil, but I think it's become the norm with words like "agile" being thrown around as synonyms for "don't have to write anything down".
I've seen this so many times on consulting gigs and with the occasional new employer. I'm hired because I'm familiar with the technologies they're trying to use, but the first major value I bring to the organization is simply getting some kind of sane process: working version control, automatic builds, test suites, one-button deploys, and so on.
Unfortunately, this is pervasive in the "real world", especially with regard to client-driven (agency) work. Deadlines beat developers almost without fail. I agree that it is destructive short term thinking. Entire weeks of programming can be destroyed in a 15-minute phone call that (re)highlights a limitation clients either didn't account for in their specification (if you can call it that) or just chose to ignore.
This isn't to say that using a language or framework a developer is familiar with is baseless, but I've heard this advice before and see it reinforced often:
1 - Hire people not skills.
2 - Success is 90% preparation.
You mean you're not interested in what a huge part of the industry is doing? Well then that explains why you don't see the benefit.
There's tons of work creating user interfaces, transform some business logic and shove it back in a DB. No one said it was going to be a life-fulfilling experience. It's just work.
Now many of these shops want a native ui, mobile ui, responsive design and a back-end developer all in one. Many times they hire for specific frameworks so that you're ready to be productive day 1.
If I were staffing up a team to do a CRUD app, or even more complex, I'd staff up with JS developers.
It's 2017, We've had desktop computers for 35 years and most of the people I know working in various industries still manage a huge chunk of their work in email and excel because it's hard for their management to understand the benefits of automation or why they'd make an investment in the longer term with good software, I know of one company thats in the FTSE250 that manages it's entire pallet and tray inventory by using excel spreadsheets on a shared drive and sending people from the office to sites to look whats there (they order 100K+ Trays at a time).
Yes, you chopped off the important half of the sentence, and responded as if I hadn't written it. I said that I wasn't interesting because CRUD apps are already so easy to write in many different frameworks.
Let's assume that what you're saying is true—that most shops want all of those skills rolled into one person. The people I've met that are good at both front-end and back-end development are comfortable in multiple languages to begin with. The developers who only know JavaScript and are not comfortable in other languages are not good full stack developers.
But I don't believe that this is true to begin with, most places I've seen or the places where my friends work have people who focus on front-end and people who focus on back-end. There's just too much of a crazy front-end landscape to expect magic from someone who doesn't live in that world, and back-end is its own world.
You can reuse code / modules.
You Don't suffer from context switching inherent with jumping between languages.
Also, people act like JavaScript is a bad language purely because it is not strictly typed. It's an incredibly fast and robust language with a vibrant ecosystem -- something I'd argue is more important than pure technical bullet points.
Instead of writing "a quick Python script" for personal use, I now write "a quick node script" because there's almost no thinking required on my part. Just require the packages and throw them together.
Not even Python has this package-completeness.
While npm has a lot of packages, Python has a lot of fully matured, well-tested and well-documented packages.
It's apparent to me that there are a lot of low quality, duplicate and otherwise unstable npm packages.
Don't get me wrong, I actually like npm too but I don't think the Python comparison is even in the same ballpark.
If you are a developer then you should invest your time and be able to learn and use the best tool for the job.
If however you are something like a Product manager then learning JS is much more valuable time investment. It is the one language that will, currently, run anywhere ... Backend, Frontend, Side end, whatever.
You can quickly get good at JS to the point of being able to prototype the full app stack and come up with something that works, goto market and fail. Should you find your self in the unlikely position that your product meets its success, then you can go ahead and hire a Go/Elxir/WebASM whatever guy to optimize this and needs larger throughput.
You have 24 hours in day, 6 to sleep, 3 to breath, 1 to eat. How do you want to spend the remaining 14 ? You get good at what you practice :)
If you are a web shop you have javascript. Using node.js allows you to eliminate one extra language.
Is it perfect? Definitely not. Is it best for everything? Probably not the best for anything. But, it's good enough for most stuff. It doesn't make sense to incur the burden of another language for a one off task.
This is also an excuse for NIH ( never invent here ) where people try to shoehorn an OSS product even if it doesn't fit their needs .
class Shape {
constructor (id, x, y) {
this.id = id
this.move(x, y)
}
move (x, y) {
this.x = x
this.y = y
}
fixed_offset(off_x,off_y) {
return () => {
console.log(`offsets x: ${off_x} y: ${off_y}`)
return [this.x + off_x, this.y + off_y]
};
}
}
var Shape = function (id, x, y) {
this.id = id;
this.move(x, y);
};
Shape.prototype.move = function (x, y) {
this.x = x;
this.y = y;
};
Shape.prototype.fixed_offset(off_x,off_y) {
var self = this;
return function() {
console.log("offsets x: " + off_x + " y: " + off_y`)
return [self.x + off_x, self.y + off_y]
}
}My general (perhaps wrong) impression is that other languages commonly used in backends are moving toward async io, usually through maturing libraries.
It's true that other languages add async models (or emphasize those that they already have), but eg. in the case of Java you're sitting on 20 years of synchronous library and custom code, and it's not clear moving to async is worth it at this pont.
Many of the applications people think of for node.js end up being "glue", much like python, and can live within this constraint for a very long time, where the I/O optimization is a nice benefit.
Node.js is garbage (well, good for simple crud apps) and so is JS.
And why not use a shared memory server?
> Operations started adding rules with 100,000s of domains, which caused a single set of rules to be about 10mb large ... If we weren’t using node.js, we could cut this bandwidth by 4 as there would only be one connection to the Redis cluster retrieving rule sets.
Maybe a 10mb json string isn't the best design decision.....
Or you know, you could have one node process connect to the Redis server, and have the local processes read from a shared memory server.. Or you could not store your rules as a 10mb friggin JSON string..
> When rule sets were 10mb JSON strings, each node.js process would need to JSON.parse() the string every 30 seconds. We found that this actually blocked the event loop quite drastically
Well then do it in another thread and save it to shared memory. Maybe, just maybe, JSON strings aren't the tool for the job here.
As the above comment clearly points out, there are workarounds to make things work. Still, when I think about the amount of time and effort that goes into debugging systems when they hit limits like the author mentioned, I imagine most of the the benefits gained by using a language like Python or JavaScript go away.
It has happened to me before. I design something, then I run it in multiple CPUS and it doesn't make sense anymore...
Or realize that if try to scale the current design doesn't hold.
Node.js running in a single thread is a good thing if you know how to work with it. Or if you really need multiple threads, use another PL.
Or you could write it in C++ and bind it to Node.js. And run it as a background process. Or spin up a worker? there seems to be multiple solutions here...
We go great length to figure out which attributes to fetch and add limits to all our sql queries. These are best practices but with node they are must.
This is completely standard and the only way to do node in-memory caching. Think of each worker as a completely independent node process, which is only bound to the cluster by a master process which has the ability spawn and kill child cluster processes.
This isn't accurate you can use shared memory. There are a few modules that implement this. In addition, you can offload the JSON.parse to the dedicated "caching" process that updates the shared memory.
Ok nevermind, google is my friend: https://github.com/PaquitoSoft/memored
I can see where this would come in handy. But at 240MB total resident memory per CPU across 4 node workers that OP describes, I wouldn't hassle with it.
That said, I can imagine other languages (like Java or Go) could still end up being more efficient than Node.
Similarly, the memory issue isn't so much that a single copy of the table takes a lot of space, but rather that they need to store 4 copies of the table -- because they're running 4 different processes in order to utilize multiple cores.
Both of these issues are specific to nodejs.
Actually, that's its fundamental design. They reduced everything down to a very small core with very little features, so things would be obvious and you don't have to learn or remember much. It's refreshingly simple!
With that said, I'd say they reduced it too far down. There's no generics so you end up using `interface{}` everywhere which often leads to issues due to its late binding. Or you end up just using codegen tools, IIRC.
Also since there are no exceptions, you end up with constant checks for error code returns, which end up usually just being strings and not much else. Not saying exceptions are the best way to approach error handling, but they do allow you to reverse through an entire function call stack and clean up any state along the way, along with adding more granular error information you can write handlers to react to. Go reminds me of the pain that was C error handling and juggling error codes.
I don't think I understood your point. But is not Node.js supposed to not block long lasting tasks?
There's not enough detail to be sure, but this sounds more like "when a relational database would be a better idea than redis."
Edit: That is, pushing the evaluation of the rules down...rather than pulling a kv and walking 10MB (of JSON?) to get to the small number of rules that apply for the transaction.
Unless you know for sure what limits you will hit - it makes sense to iterate quickly and find out. Then, if the service is actually hitting limits (and probably not the ones you thought) - re-write it in a multi-threaded concurrent language like go, elixr etc - or a language designed to solve the actual problems the service is hitting (which might be disk i/o or other infrastructure level things not language choice)
-Having a hard time taking anything this guy says seriously
There were probably opportunities for the author to architect the system in ways that were better suited to node (given that was the chosen platform), but the architecture choices were not unreasonable by design. These are some good things to consider when architecting a system, and considering node as the platform.
I'm not sure I agree that node is the "perfect for simple CRUD apps" though