What they don't say in this panegyric to node is that..
1. The language (js) is absolutely horrific.
2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics.
3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug.
4. It is designed to the lowest possible specification for development: web developers.
5. js package mgmt and build tools are a running joke.
JavaScript is Eating the World
71–80 of 323 posts
Re: JavaScript is Eating the World
#72Earlier quoted context omitted.
I tried your code snippet on my inferior Windows OS and inferior IE Edge browser. The tab stopped functioning. I opened a few other tabs and continued to work. Eventually IE showed a notice that the tab had stopped responding - I had the option to close the tab or recover the webpage. I clicked 'recover webpage', the page was refreshed and I could continue using it. Truly, Javascript is eating the world. Or perhaps t…
Do you deny that implementations are part of the language? If the Javascript specification left this out, what other implementation gotchyas exist for them to exploit?
[deleted]
Re: JavaScript is Eating the World
#73Earlier quoted context omitted.
Personal experience: NPM can be mind-bogglingly slow in Windows. In my previous day-job, an NPM install on Windows 7 could take hours, for some reason. That's NPM 3 with about 20 dependencies on a small project. NPM on Windows also had other problems such as Python path is wrong or C++ compiler is missing. Then we switched to Yarn. Uncached install took about 2-3 minutes, and cached install would finish in seconds. R…
Still a bigger fan of Yarn here. My personal tests have Yarn running a bit faster still, but I also like that Yarn's command syntax is easier. NPM seems content with making a million aliases of everything and it's annoying. I think they even added 'add' from Yarn. Also, Yarn's run command can be used to run locally installed NPM binaries, not just NPM scripts. i.e., you can do `yarn run -- webpack` and it will run th…
FWIW npm 5 comes with npx [0] which basically does similar things. If you run npx webpack it would use the local copy of webpack or even install one run it and discard it.
Re: JavaScript is Eating the World
#74Earlier quoted context omitted.
I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.
It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
What does it warn you about? Not trolling, honest question.
Re: JavaScript is Eating the World
#75What you build is infinitely more important than what you built it with. If someone writes a better Google the users won't care if it's using Javascript, Rust, or QBasic. They'd still be all over it.
I had a client that asked me to rewrite our software in JS. He didnt know anything about programming but said he preferred JS.
I haven't ever written professional software, but I just took a software engineering course and what I learned is that what technology stack to use is none of the clients business.
Re: JavaScript is Eating the World
#76JS has the appeal that it's something a lot of people already have good amounts of experience with. And ES2015+ features add to the learning curve, but also give some much needed aid to existing problems; it's easy to pick up on async/await when you already know how promises work. Meanwhile, trying to find Go developers can be a challenge. And the learning curve is low, but there's plenty of low-level gotchas like de…
I'm beginning to think npm has joke potential like regex. "I had a problem. I started using regex and now I have two problems." Becomes... "I had a problem. I ran npm install and now I have 21,735 problems."
I've got 99 problems, but npm isn't 21,735 of them.
Re: JavaScript is Eating the World
#77We live in dark times.
Re: JavaScript is Eating the World
#78Earlier quoted context omitted.
Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have…
Using non-blocking IO is a very old trick. Even nginx does exactly this, and it's written in C. The ability to use non-blocking IO does not make a language unique in any real fashion.
It has nothing to do with the language, there were other serverside javascript frameworks before node; they didn't take off (e.g. Narwhal).
Node's success has everything to do with the environment itself in combination with the language. The node runtime, the associated stdlib, and most open source/3rd party modules have been written for a non-blocking runtime from day #1. The same stuff can be achieved in plenty of other languages/stacks (e.g. Python + Twisted), but you have much more work to do validating that every single library you use plays nice with async io, sometimes you have more event loop housekeeping responsibilities, etc...
Re: JavaScript is Eating the World
#79We live in dark times.
It's okay. Javascript may be eating the world, but the Javascript world is eating itself.
Re: JavaScript is Eating the World
#80Earlier quoted context omitted.
What computations do you do in a webserver which hosts a REST API? Most of it is simple CRUD connected to a database, possibly with an auth layer on top, which is pretty much what you describe, passing IO through to a database and back.
Compression, hash computation, regular expression routing lookups, parsing text, building and serializing datastructures, reading and writing caches; I could go on. Sure, JavaScript (and Ruby and Python) are usually fast enough with modern hardware - but we can't pretend there's no cost.
deserializing data structures is a great example. JSON.parse is SLOW. all it takes is a bit of bad code that doesn't do any checking of input size/etc... and if an authoritative source starts sending larger payloads than usual, your node process is horked. Granted, that's not a problem remotely specific to node, it just has a bigger effect in a node env.