4 ms·
ES6 and ES7 fixes everything here except strict typing, by the way.
by jayajay 10y ago
ES6 and ES7 fixes everything here except strict typing, by the way.
- Arnavion 10y agoasync-await is in neither of those, though TS does support it and downlevels it to ES5/ES6.
- nrjdhsbsid 10y agoAlso still no multithreading, which causes callback hell in the first place
- jayajay 10y agoLike others have said, callback hell is fixed with async/await, yield/generators, and even lightweight libraries like fibers and promises. Personally, I dislike promises, and I don't use them at all. That said, you have plenty of other choices when it comes to style. The single-threaded nature of node.js was very intentional and was thought to be a better design choice for a certain class of applications (IO focused, not computation focused) like routers, web servers, and other networked applications.
- nrjdhsbsid 10y agoSingle threading was not intentional. It's because they used js, now they're trying to sell it as a feature. They've tried to implement threading several times but it's a huge change to the V8 engine and js isn't designed for it. Promises/async were needed to make the language usable because it's stuck on a single thread. The normal solution is to just use multiple threads and people have been doing g that for many years in other languages
- jayajay 10y ago"its because they used js" But, this was intentional. As for them implementing threading, I am not sure about the history here. Was it like: "We used JS and knew we were going to have a ST environment, but because people wanted MT, we tried..." Or, was it more like: "Let's use js and we'll of course need MT like everything else... oh wait... nvm."?
- Matthias247 10y agoI second that. JS is singlethreaded by intention, and IMHO it's ok that way and the reason why the ecosystem mostly works and async libraries can be reasoned about. There are JS implementations (like Nashorn on JVM) which are multithreaded, and imho they would be a much poorer choice. Once you have callbacks and multithreading in a single system there are dozens of things you need to care about (from which thread will callback be fired, how to synchronize that with the remaining logic, ...) and the complexity grows immensely. I think that's exactly the scenario that the JS inventors wanted to circumvent.
- nrjdhsbsid 10y agoJava and c# manage threads+async just fine. You're overestimating the difficulty of using then together. In practice you just add the word async or await and go about things normally like in node. Js is single threaded because it was designed that way, not because it's a good design
- geon 10y agoWith proper use of promises, async/await and generators, there is no reason for callback hell. But why would you need threading? 99% of the time will be spent waiting for io. And you can allways spawn a process if you need something computationally heavy. If you max out the core running your node thread, you are just about to need a second machine and load ballancing anyway.
- nrjdhsbsid 10y agoThat's just not true. With SSD's and cheap ram less time than ever is spent waiting on IO. Almost everything these days is CPU bound and it's only going to go more in that direction as the speed disparity between storage and memory shrinks
- darpa_escapee 10y agoInsert relative access times chart here.
- jayajay 10y agoYour statement is true if we only consider a single machine. But, people using node.js are most often writing networked applications (right?).
- geon 10y agoDo you count waiting for io from the db? I know in my apps there is very little processing going on in node itself.