|
I've perused COBOL for a few months now, and I haven't seen any heavily Node.js-oriented threads. Has this just not been covered with a megathread, or does COBOL just dislike Node? I'm so confused.
|
#
?
Feb 18, 2015 16:51
|
|
|
|
| # ? Apr 26, 2024 05:00 |
|
|
El Marrow posted:I've perused COBOL for a few months now, and I haven't seen any heavily Node.js-oriented threads. Has this just not been covered with a megathread, or does COBOL just dislike Node? Node.js is stupid and the community is poo poo.
|
|
#
?
Feb 18, 2015 19:38
|
|
|
There's a particular fondness for it in the coding horrors thread.
|
|
#
?
Feb 18, 2015 19:46
|
|
|
I contributed to Node.js in its early days (just a simple bugfix) and have regretted it ever since. See also What the hell is going on in webdev land FakEdit: Good god that thread is from 2013.
|
|
#
?
Feb 18, 2015 19:59
|
|
|
Bruegels Fuckbooks posted:Node.js is stupid and the community is poo poo. It's incredible how staggeringly wrong you are.
|
|
#
?
Feb 18, 2015 22:15
|
|
|
El Marrow posted:It's incredible how staggeringly wrong you are. Like, the idea behind node.js is offensive to me. "Let's take javascript, and run it on the server." gently caress, man, seriously? I don't like Ruby on Rails or Django either but the world didn't need a bunch of assholes trying to get javascript to run on a server. They also like trying to make a "native like" platform for web apps, but using javascript for the user interface. There are better tools for doing both of these things. Just because it's possible to write anything in loving javascript doesn't mean it's a good idea.
|
|
#
?
Feb 18, 2015 23:06
|
|
|
El Marrow, what other tools have you used for web development?
|
|
#
?
Feb 18, 2015 23:11
|
|
|
pre:<sarehu> .q dentist 66 <skybot> sarehu: [66/90] 2013-10-24 <dentist> that's why node.js exists: terror at the thought of having to learn another language (because JS is so full of pitfalls that they assume all languages are this bad)
|
|
#
?
Feb 18, 2015 23:24
|
|
|
NodeJS is legacy. Please refer to the io.js thread, OP.
|
|
#
?
Feb 18, 2015 23:35
|
|
|
Avenging Dentist posted:
An appropriate number for that 16-bit opinion on a 32-bit language.
|
|
#
?
Feb 18, 2015 23:36
|
|
|
Bruegels Fuckbooks posted:Like, the idea behind node.js is offensive to me. "Let's take javascript, and run it on the server." gently caress, man, seriously? I don't like Ruby on Rails or Django either but the world didn't need a bunch of assholes trying to get javascript to run on a server. They also like trying to make a "native like" platform for web apps, but using javascript for the user interface. There are better tools for doing both of these things. Just because it's possible to write anything in loving javascript doesn't mean it's a good idea. I don't know much of Node but the tech lead of quite a successful local startup gave a talk about why they use it, and they have some good points. Javascript and node.js are made for and optimized for the web and networking from the ground up, rather than relying on libraries. Most developers need to know Javascript anyway these days, so why not use it on server. Very easy to create and integrate with JSON/RESTful services, because duh. The runtime is very lightweight compared to JVM and that of many other languages. Compile times don't exist, so devs are more productive and deployment is easy. NPM is pretty cool. It's single-threaded but asynchronous, so you get many benefits of multithreading but without the complexity and caveats. They said they design what components they can to be stateless and just run [number of CPU cores] instances of node (behind some kind of load balancer?), and if that works, then they can easily scale it to many servers as well. Etc.
|
|
#
?
Feb 18, 2015 23:52
|
|
|
pigdog posted:Very easy to create and integrate with JSON/RESTful services, because duh. Would you mind elaborating on this point? Why is it "duh"?
|
|
#
?
Feb 18, 2015 23:55
|
|
|
pigdog posted:Javascript and node.js are made for and optimized for the web and networking from the ground up, rather than relying on libraries. Javascript is not optimized for networking at all. It's not optimized for the web either (not sure what you mean by optimization, but if you mean in terms of language design... from a web server perspective, it certainly is not). Node.JS is not optimized for networking either. It has a networking library, like anything would have. pigdog posted:Most developers need to know Javascript anyway these days, so why not use it on server. Because of reasons, such as callback hell being worse than using threads, and being dynamically typed being worse than being statically typed. pigdog posted:Very easy to create and integrate with JSON/RESTful services, because duh. Actually, it's because there's a JSON parser in the library, and an HTTP server, just like there is with other languages/frameworks you'd use for web development. Being Javascript gives it no special privileges to either aspect. pigdog posted:The runtime is very lightweight compared to JVM and that of many other languages. Compile times don't exist, so devs are more productive and deployment is easy. Or you could use other languages that are better, also have lightweight runtimes (except you're running a server so having the JVM is not a problem) and you have to hit a deploy script anyway, it's not like you're editing files in place. pigdog posted:NPM is pretty cool. If it's so cool what is Bower for, and don't Python or Ruby or Java and the like have ways to get packages too? Yes, they do. pigdog posted:It's single-threaded but asynchronous, so you get many benefits of multithreading but without the complexity and caveats. You get the complexity and caveats of event-based programming, which is what multithreading solves. Guess what caveats you get of multithreading: there aren't really any if you're writing a sane web app that only talks to a database and global caching stuff, and doesn't have request handlers sharing global state. pigdog posted:They said they design what components they can to be stateless and just run [number of CPU cores] instances of node (behind some kind of load balancer?), and if that works, then they can easily scale it to many servers as well. Etc. Which is not some Node-specific solution or good thing about Node.JS.
|
|
#
?
Feb 19, 2015 00:04
|
|
|
IBM have integrated Java and COBOL, I would not be in the least bit surprised to see Node.js and COBOL, oh wait.
|
|
#
?
Feb 19, 2015 00:18
|
|
|
The point is they are making do with Node and without threading, in several datacenters and servicing hundreds of thousands of users -- and scaling across servers is more important anyway. No doublt they could have just as well written the thing in COBOL, but node.js seems to be working for them and that's cool. For what it's worth npm is rather neat and effortlessly handles version conflicts which in the Java world be jar hell.
|
|
#
?
Feb 19, 2015 00:52
|
|
|
sarehu posted:El Marrow, what other tools have you used for web development? SERVERSIDE: C# / ASP.NET VB.NET C + cURL Python / Django Ruby / Rails CLIENTSIDE: Angular.js jQuery Knockout Ember.js Handlebars Atom Shell EJS ERB Deus Rex posted:Would you mind elaborating on this point? Why is it "duh"? Because it's a natural fit to have your serverside code natively speak the same language as the services you're drawing or sending data to/from. Duh. Bruegels Fuckbooks posted:Just because it's possible to write anything in loving javascript doesn't mean it's a good idea. You're right, but in this case, it's a fantastic idea. Node.js achieves mind-blowing benchmarks, is remarkably stable, and it allows an entire dev shop to work in the same language across the stack. If you've ever managed a development team, you'll immediately see value in this. more like dICK posted:NodeJS is legacy. Please refer to the io.js thread, OP. I was really hoping someone would bring up io.js!  sarehu posted:Javascript is not optimized for networking at all. It's not optimized for the web either (not sure what you mean by optimization, but if you mean in terms of language design... from a web server perspective, it certainly is not). Node.JS is not optimized for networking either. It has a networking library, like anything would have. And it's almost poetic that its benchmarks and usability blow almost everything else out of the water. sarehu posted:Because of reasons, such as callback hell being worse than using threads, and being dynamically typed being worse than being statically typed. Which is a matter of opinion. Mine being that if you're afraid of callbacks, you're a pussy. sarehu posted:Actually, it's because there's a JSON parser in the library, and an HTTP server, just like there is with other languages/frameworks you'd use for web development. Being Javascript gives it no special privileges to either aspect. That's funny. Last time I checked, you had to import a JSON module into Python to do that. sarehu posted:Or you could use other languages that are better, also have lightweight runtimes (except you're running a server so having the JVM is not a problem) and you have to hit a deploy script anyway, it's not like you're editing files in place. You're right about better languages. Javascript + Node is the ultimate in settling. Sorry, but the JVM is ALWAYS a problem. Everything about the Java ecosystem is worse than cancer. sarehu posted:If it's so cool what is Bower for, and don't Python or Ruby or Java and the like have ways to get packages too? Yes, they do. And none of them have accumulated as many robust and maintained packages in their history as NPM has. As far as NPM vs Bower, perhaps you should take a look at how their dependencies are structured. You might find your answer there. sarehu posted:You get the complexity and caveats of event-based programming, which is what multithreading solves. Guess what caveats you get of multithreading: there aren't really any if you're writing a sane web app that only talks to a database and global caching stuff, and doesn't have request handlers sharing global state. That's cool. Let's compare benchmarks and scalability. In my last position as chief architect of a startup in Atlanta, I ran concurrency and scalability tests until my eyes bled. My jaw hit the floor when I was able to attain 270ms transaction times on high-throughput requests to 250k simulated concurrent users. The beauty of Node in this regard is the event loop, which is the same reason why Nginx is vastly faster than Apache. Edit: This post came off as a bit salty  To each his own.There are two things in this industry I can't stand: 1. People who are intolerant of other people's languages 2. Java El Marrow fucked around with this message at 01:06 on Feb 19, 2015 |
|
#
?
Feb 19, 2015 01:00
|
|
|
El Marrow posted:Node.js achieves mind-blowing benchmarks lmao
|
|
#
?
Feb 19, 2015 01:06
|
|
|
sarehu already covered the gamut is his rebuttal, but here's more.pigdog posted:I don't know much of Node but the tech lead of quite a successful local startup gave a talk about why they use it, pigdog posted:Most developers need to know Javascript anyway these days, so why not use it on server. Also, JavaScript is a terrible language. It's tolerated on the front-end due to necessity and the fact that there's nothing that can replace with the same degree of browser compatibility. That said, it's been around long enough in web browsers that frameworks have sprung up to make it suck less. In contrast, there's few constraints on which language/framework to use on the server, and thus, there exists a variety of mature, well-thought-out language/framework combinations. Here, node doesn't provide anything fundamentally new at all, aside from the novelty of "having the front-end and back-end in the same language!" pigdog posted:Very easy to create and integrate with JSON/RESTful services, because duh. pigdog posted:Compile times don't exist, so devs are more productive and deployment is easy. pigdog posted:NPM is pretty cool. pigdog posted:It's single-threaded but asynchronous, so you get many benefits of multithreading but without the complexity and caveats. So, the deal here is that mature languages support both threading and event-driven models, so you can write code using whichever approach is better suited for your purpose. Node only supports the event-driven model because V8 doesn't support multiple threads. Node hipsters spin the "async sauce" as an advantage, but honestly it's a major limitation of the platform that is, at best, a neutral point for folks who really believe that event loops are always superior to threads. ExcessBLarg! fucked around with this message at 01:20 on Feb 19, 2015 |
|
#
?
Feb 19, 2015 01:08
|
|
|
Is 270ms supposed to be impressive?
|
|
#
?
Feb 19, 2015 01:09
|
|
|
Bruegels Fuckbooks posted:Node.js is stupid and the community is poo poo.
|
|
#
?
Feb 19, 2015 01:11
|
|
|
El Marrow posted:Because it's a natural fit to have your serverside code natively speak the same language as the services you're drawing or sending data to/from. Duh. I don't follow: if the language you're talking about is the language the applications behind those services was written in, I'm not sure I see any advantages or natural fits unless you're using some kind of language-specific RPC mechanism. If the language you're talking about is JSON, unless I misunderstand something about the relationship between JSON and Javascript it seems to me that Javascript doesn't offer any particular advantages over other languages in "speaking" JSON.
|
|
#
?
Feb 19, 2015 01:12
|
|
|
It's because the J in JSON stands for JavaScript duh
|
|
#
?
Feb 19, 2015 01:16
|
|
|
Steve French posted:Is 270ms supposed to be impressive? With 250k concurrent users on a single box? LOL YEAH. I'd say so. Gawd drat. The elitism is strong here.
|
|
#
?
Feb 19, 2015 01:16
|
|
|
El Marrow posted:With 250k concurrent users on a single box? LOL YEAH. I'd say so. Concurrent users is not meaningful by itself.
|
|
#
?
Feb 19, 2015 01:17
|
|
|
El Marrow posted:That's cool. Let's compare benchmarks and scalability. In my last position as chief architect of a startup in Atlanta, I ran concurrency and scalability tests until my eyes bled. My jaw hit the floor when I was able to attain 270ms transaction times on high-throughput requests to 250k simulated concurrent users. The beauty of Node in this regard is the event loop, which is the same reason why Nginx is vastly faster than Apache. were you running on like an arduino? your chromebook?
|
|
#
?
Feb 19, 2015 01:19
|
|
|
What is a high throughput request
|
|
#
?
Feb 19, 2015 01:22
|
|
|
I guess the OP closed this out of shame. I don't like that.
|
|
#
?
Feb 25, 2015 03:51
|
|
|
I thought a mod closed it for being a bullshit magnet.
|
|
#
?
Feb 25, 2015 04:23
|
|
|
I use Node for most of my side projects, but would I write a 10k SLOC webapp in it? No. Like has been touched upon, the callback hell is so very bad. It makes the developer have to reason about code much more and looks ugly as all hell. ES6 and ES7 (promises and async/await) will go far to help alleviate this hangup.
|
|
#
?
Feb 25, 2015 15:55
|
|
|
Hi guys, great thread! I'm a bit of a Node 'newbie' but I can tell you that if you don't like callbacks, there are blocking versions of all the IO library calls That's what I'm using for my current project, a FreeBASIC to C++ compiler written in Node.js.
|
|
#
?
Feb 25, 2015 16:46
|
|
|
Fib posted:Hi guys, great thread! I'm a bit of a Node 'newbie' but I can tell you that if you don't like callbacks, there are blocking versions of all the IO library calls Thus obviating the raison d'être of using node in the first place.
|
|
#
?
Feb 25, 2015 17:50
|
|
|
Fib posted:a FreeBASIC to C++ compiler written in Node.js. lol
|
|
#
?
Feb 25, 2015 18:05
|
|
|
I like the idea of using node to pre-render JS frontend stuff on the server. Having two different sets of view rendering code sucks, and so does serving a blank page that turns into an actual page five seconds later.
|
|
#
?
Feb 25, 2015 18:07
|
|
|
Node.js is nice because it gave front-end web development a decent package manager to rule them all. Not sure if I'm much of a fan of it for API endpoints though... getting proper stack traces from Node.js exceptions is not very easy. Node.js fits better as a proxy/middle-tier if you really want to use it on the server, backed by an API written in something else. Stoph fucked around with this message at 01:15 on Feb 26, 2015 |
|
#
?
Feb 26, 2015 01:13
|
|
|
Plorkyeran posted:I like the idea of using node to pre-render JS frontend stuff on the server. Having two different sets of view rendering code sucks, and so does serving a blank page that turns into an actual page five seconds later. this is a genuine use case for javascript on the server - but it might still not count for node. using node for ssr, you have the overhead of process creation and startup on every web request - or at best, serialised ipc.. to a manually managed pool of processes since they're each single threaded. that's a good way to waste hundreds of milliseconds and hit scaling bottlenecks. it's easier just to embed v8 or some other javascript engine in-process of whatever you're using for the server.
|
|
#
?
Feb 26, 2015 08:18
|
|
|
Gul Banana posted:this is a genuine use case for javascript on the server - but it might still not count for node. using node for ssr, you have the overhead of process creation and startup on every web request - or at best, serialised ipc.. to a manually managed pool of processes since they're each single threaded. that's a good way to waste hundreds of milliseconds and hit scaling bottlenecks. it's easier just to embed v8 or some other javascript engine in-process of whatever you're using for the server. honestly, maybe there's really a use case for doing something like that (like having to support IE8 or some other bullshit), but talking about pre-rendering javascript on the server to "improve performance" is a big sign that I'm going to have to throw out the project and start from scratch - up there with "javascript caching and data layer." Both are signs that you have old people trying to do front-end work.
|
|
#
?
Feb 26, 2015 13:26
|
|
|
Bruegels Fuckbooks posted:honestly, maybe there's really a use case for doing something like that (like having to support IE8 or some other bullshit), but talking about pre-rendering javascript on the server to "improve performance" is a big sign that I'm going to have to throw out the project and start from scratch - up there with "javascript caching and data layer." Both are signs that you have old people trying to do front-end work. Uh, pregenerating the HTML for the initial page load (instead of just sending down data and having it generated client-side) is a totally worthwhile thing to do for reducing page load time. Unless by "old people" you mean "people who care about performance" or something? (Your users care about performance. This is objectively measurable.)
|
|
#
?
Feb 26, 2015 14:12
|
|
|
search engines are also a big fan of crawling pages with actual content, rather than an empty <div id="react-mount">
|
|
#
?
Feb 26, 2015 14:48
|
|
|
Bruegels Fuckbooks posted:honestly, maybe there's really a use case for doing something like that (like having to support IE8 or some other bullshit), but talking about pre-rendering javascript on the server to "improve performance" is a big sign that I'm going to have to throw out the project and start from scratch - up there with "javascript caching and data layer." Both are signs that you have old people trying to do front-end work. No. Just no.
|
|
#
?
Feb 26, 2015 15:38
|
|
|
|
| # ? Apr 26, 2024 05:00 |
|
|
Gul Banana posted:this is a genuine use case for javascript on the server - but it might still not count for node. using node for ssr, you have the overhead of process creation and startup on every web request - or at best, serialised ipc.. to a manually managed pool of processes since they're each single threaded. that's a good way to waste hundreds of milliseconds and hit scaling bottlenecks. it's easier just to embed v8 or some other javascript engine in-process of whatever you're using for the server. Embedding v8 in your main application server would probably be better, but it certainly wouldn't be easier than using pre-existing solutions. A load-balanced node worker pool that doesn't add hundreds of milliseconds of latency is a rather solved problem, and since it doesn't need to be public-facing you don't even really need to be able to scale the worker pools.
|
|
#
?
Feb 26, 2015 16:59
|
|