Talk:Node.js/Archive 1

Archive 1

Node History

This article has some nice info on node and its history. Can be used to expand the article.--175.136.62.233 (talk) 19:25, 11 September 2011 (UTC)

Good one, thanks. I've just added to the article as a source for an existing statement, but we should use it more widely. Cheers, CWC 08:43, 30 November 2011 (UTC)

asynchronous i/o

i think this needs a discussion on asynchronous i/o, and an explanation of the difference between asynchronous-io/web-workers and threading/concurrency (as i understand it, asynchronous i/o, especially for server i/o, is a crucial use of of node.JS). perhaps also we can discuss why people have see node (especially in the context of server-scripting with asynchronous solutions) as providing a performance/scaling advantage (despite the performance compromised by the use of a high-level interpreted language, JS). also along the lines of performance, maybe this article also needs more thorough discussion of the google V8 engine for JS rather than just a mention and link? 50.74.192.11 (talk) 15:22, 4 October 2011 (UTC)

Yeah, async I/O is a core feature. The article now has links to relevant Wikipedia articles, which helps, but a proper explanation would be better. CWC 08:43, 30 November 2011 (UTC)

Logo

Here is a svg logo, wish it can help. No need to cite any source, do wath the f. you wantwith it : http://wikisend.com/download/313448/nodejs.svg — Preceding unsigned comment added by 90.18.244.150 (talk) 17:25, 18 October 2012 (UTC)

Wrong link. Graphnode (talk) 10:44, 24 October 2012 (UTC)

Frameworks

There used to be a section on frameworks but it was removed for some reason. This section was of particular interest for people who are interested in Node.js. The large number of developers who visit the Node.js Wikipedia page will be wondering how they can use Node to make apps - Currently these users are not being catered for. I propose we bring back the frameworks section and if it ever gets out of control (in terms of length), we can trim the list down to only include the most popular frameworks. I think that there are two few frameworks at the moment to worry about this. — Preceding unsigned comment added by 110.175.94.70 (talk • contribs)

It was removed because listings of external links are supposed to be avoided and because wikipedia is not supposed to be a directory. Perhaps a list of such links could be created on a site that is supposed to be a link directory, such as dmoz.org - MrOllie (talk) 16:23, 13 November 2012 (UTC)

Date problem

I'm reading "February 15, 2013; 0 days ago" on the right info box... it's the 19th. This might be a larger Wikipedia problem, since the "date" filter/tag is being used (maybe the server time is off), but it's worth noting here. — Preceding unsigned comment added by 66.176.55.151 (talk) 17:33, 19 February 2013 (UTC)

Strengths / Weaknesses, Tradeoffs, etc.

It would be highly worthwhile to discuss the strengths of Node.js, as well as the weaknesses and tradeoffs that it carries with it. For example, there should be a brief description of some various circumstances in which Node.js may be used. The article also says nothing about the Read-Eval-Print-Loop, which is key to understanding. Perhaps we can compare how processes are run on Node.js to other implementations - the following image (at the top of the page) is handy for this, and an example used by Dahl himself. Perhaps we can also provide a list of some examples of companies / web sites that use Node.js (I heard Yahoo! and Facebook do). Hopefully I'll contribute when I have more time. Cheers! Danielbullis (talk) 05:43, 2 March 2013 (UTC)

JXcore

Keep JXcore information out, especially in the lead. This it the Node.js article, not the JXcore article. When JXcore gains traction/significance you can warrent a creation of its own article. You don't go about adding Palemoon info into the Firefox article just because its a fork. Get real.

Whoever added the "Node.js is multi-threaded" crap into the lead section, please realize that you cannot confuse two independent technologies and document exclusive features as if they are shared. You completely confused the threading note in the lead section and to avoid arguments I've moved it out of the lead into the newly created "Technical" section. -- Wonderfl ^(reply) 03:02, 15 August 2014 (UTC)

Quality

The entire article reads as if it is written by a first grader. — Preceding unsigned comment added by 193.191.136.194 (talk) 13:51, 2 June 2014 (UTC)

Agreed. Consider the line below found under the Uses heading: "Fast file upload client: when there are big file to be uploaded, to make sure that they don't block so that you can upload more than one file at a time." — Preceding unsigned comment added by 41.79.220.255 (talk) 10:35, 11 June 2014 (UTC)

Agreed. I deleted that rubbish section. Thanks for pointing it out. Some idiot who knows pretty much nothing about node wrote it. And it doesn't make any sense either. Trying to clean up what I can. Since when has WP become a bunch of random blog posts merged into an "article"? -- Wonderfl ^(reply) 03:09, 15 August 2014 (UTC)

Low quality rubbish:

1. Random #JXcore info
2. Ambiguous #Criticism

Criticism

Moved here from the main article. Sounds like a copy-paste job from some random blogpost. Most of it is ambiguous. All of it uncited and unproved.

1. "certain development issues"? What? Where? How?
2. "some issues still exist"? What issues?
3. "can add a learning curve burden"? That's the whole point of node, async event-drivven programming. If you are a JS newbie, use JS, not node.
4. "inherently adds more complexity". Idiot.
5. "loosely-typed with object-orientation abilities" .. "object-orientation"? Are you even a programmer or have you just read JavaScript for Dummies and think you are competent enough criticize node?

I don't see any reason why this crap should be moved back into the main article. Discuss here if you differ. Wonderfl ^(reply) 03:15, 15 August 2014 (UTC)

Criticism section

Node.js has some drawbacks:

• Node.js libraries are developed actively, with a high rate of change from month-to-month. This can cause version issues, instabilities and certain development issues.
• Npm shrink wrap and package.json were introduced a while back to set up standards, but the issue of standards is still a work in process and some issues still exist.
• The whole callback, event-driven, functional programming aspects of Node.js can add a learning curve burden to server-side programmers of other object-oriented languages.
• Asynchronous and event-driven code inherently adds more complexity to the code compared to synchronous code.
• As a JavaScript derivative, Node.js code is loosely-typed with object-orientation abilities. This combination can result in code that is hard to debug.

Intro needed

If the reader is not a Javascript programmer, this article does not tell them (i.e., me) anything useful at all about Node, what it is or what it does. The code snippets are only useful for people who already know about this field. Liam Proven (talk) 13:50, 2 March 2011 (UTC)

True. I tried to make the lede somewhat more understandable in a recent edit, but it requires non-programmer readers to click on wikilinks. If anyone wants to expand on my work, please go for it. Cheers, CWC 08:43, 30 November 2011 (UTC)

It might be useful to explain that this is server-side javascript :-P --2001:980:331A:1:225:22FF:FE7D:8A27 (talk) 22:26, 3 November 2012 (UTC)

Is it? I thought Javascript requires DOM bindings? Without it, it seems to be just another ECMAScript application. Am I missing something?--89.146.13.103 (talk) 11:57, 27 June 2014 (UTC)

First, "Node.js applications are designed to maximize throughput and efficiency". Then, "It is commonly used for real-time applications due to its asynchronous nature". Unfortunately applications can't be both designed to maximize throughput *and* low, fixed latency (which is what real-time implies). So which one is it? Considering it's asynchronous, I can't see how it would be a good pick for real-time applications anyway, even in the oft miscomprehended sense of "very fast applications". — Preceding unsigned comment added by 31.221.2.61 (talk) 14:34, 18 September 2014 (UTC)

"What can we look forward in future on Node.js"

This section of the page sounds like someone is trying to sell something. 66.51.102.177 (talk) 20:13, 3 June 2014 (UTC)

Excuse me @SuperHamster:, what am I supposed to do with this statement? I think it applies to a section no longer existing. Does it have any usefulness whatsoever? -- Wonderfl ^(reply) 06:58, 10 February 2015 (UTC)

@Wonderfl: You don't really have to do anything, I'd say. As with most comments more than a few months old, it's from June 2014 so it's obviously stale. If you have to mark it with anything, I'd mark it as  Fixed. Or, start an archive and move old discussions there. It's not standard to simply remove talk page messages just because they're dated. ~SuperHamster Talk Contribs 07:07, 10 February 2015 (UTC)

@SuperHamster: Thanks for your comments. Noted. I have a habit of cleaning up articles with nonsense so I let that habit affect my behaviour on talk pages also. I'll mark it fixed as you recommended. Wonderfl ^(reply) 07:11, 10 February 2015 (UTC)

 Fixed -- This section has been removed.

NPM

Should the article mention the Node Package Manager (NPM)? It seems to have won the "package manager war" for node.js and seems to be far more popular and active than its competitors or JSAN (which the CPAN article mentions as the JavaScript package manager). -- 78.35.115.245 (talk) 10:50, 1 March 2011 (UTC)

 Fixed - I mentioned the full form in the NPM section. We have a section for package management as of 2015. Wonderfl ^(reply) 07:13, 10 February 2015 (UTC)

Need better sources, fewer External links

User:Thumperward recently tagged the article with {{advert}} and {{selfpublished}}. I've changed those to {{External links}} and {{refimprove}}, but his point still holds: the sources cited in the article tend to be written by fans of Node.js, and the external links section is too long. I should be doing other things, so I'm not going to tackle this myself. Can anyone else help out?

The problem we face is that lots of people are very enthusiastic about Node.js (for good reason, IMO), and articles about it tend to be more enthusiastic than desirable in a good source for an encyclopedia. So we have to be more careful about selecting the sources to cite than in most computing-related Wikipedia articles. Cheers, CWC 08:45, 30 November 2011 (UTC)

Seems to me that there are now plenty of third party sources. The fact that they are "enthusiastic" about node.js doesn't make them unreliable or advertising. Have therefore removed {{refimprove}}--Sjsilverman (talk) 11:49, 4 January 2012 (UTC)

WHAT? no mention of coffeescript? thats how most people write code with node .. — Preceding unsigned comment added by 160.94.87.122 (talk) 03:32, 26 February 2012 (UTC)

 Done I've written the brand-new Node.js#Overview section, every statement is cited from books on the subject and is written for average readers to understand. Hope it solves some of these issues. Wonderfl ^(reply) 06:51, 22 March 2015 (UTC)

Technical Overview Issues

The second paragraph of the Overview section under the Technical heading is absolutely terrible. For instance: "In Node.js, the fact that all I/O is implemented in an asynchronous and non-blocking way, combined with a single-threaded event-based loop, presented a novel way to implement real-time web applications."

Asynchronous vs non-blocking. http://stackoverflow.com/questions/2625493/asynchronous-vs-non-blocking

How was it a novel approach?

It almost would be easier to just delete this paragraph altogether---I don't feel like it adds anything to the article. Thoughts?

K428 (talk) 01:30, 10 March 2015 (UTC)

I agree that this article needs attention from an expert on the subject, but an expert that is NOT a Node.js fanboy! Everyone I've seen edit this article is either a total newbie or a Node.js expert that spews technical jargon that only the creators can possibly understand.

We need a good balance between technical explanation and simplicity.

Also, the Node.js team needs to understand that everyone is not a geek, and try to write a decent technical overview that communicates the product in a simple way.

Wonderfl ^(reply) 00:02, 11 March 2015 (UTC)

 Done I've written the brand-new Node.js#Overview section, every statement is cited from books on the subject and is written for average readers to understand. Hope it solves some of these issues. Wonderfl ^(reply) 06:51, 22 March 2015 (UTC)

Disputed Technical content

I've just pasted this section here. It is heavily disputed, to the point where it appears to be entirely disputed. Also, all of the statements are highly technical and do not present the topic adequately for average readers.

This removal is fine because of the newly written Overview section, that defines most of what the Technical section once did; but it includes inline citations for every point. No more arguments.

If anyone wants to salvage anything, you are free to. Add refs though.

Wonderfl ^(reply) 14:55, 25 March 2015 (UTC)

Technical

Dahl originally had the goal of creating Web sites with push capabilities such as those seen in Gmail. After trying solutions in several other programming languages, he chose JavaScript because of the lack of built-in support for streams, filesystem access, or binary objects. This allowed him to define a convention of asynchronous, event-driven I/O.

JavaScript has no unified API for I/O, allowing the developers to think about the best way to implement a modern I/O interface. In Node.js, the fact that all I/O is implemented in an asynchronous and non-blocking way, combined with a single-threaded event-based loop, presented a novel way to implement real-time web applications. Node.js can therefore keep many connections alive transparently without having to reject new incoming connections.

Node.js applications are designed to maximize throughput and efficiency using non-blocking I/O and asynchronous events. It is commonly used for real-time web applications due to its asynchronous nature. Node.js internally uses the Google V8 JavaScript engine to execute code, and a large percentage of the basic modules are written in JavaScript.

Node.js is influenced by other models, such as the Ruby Event Machine and Python's Twisted model. The difference between alternatives is the implementation of the event loop as a language instead of a library. Unlike traditional models, which use blocking calls, Node.js does not have event-loop calls. Instead, Node.js enters the loop after executing the script, based on how JavaScript works. Ruby's Mongrel Web server was another source of inspiration.

Node.js applications usually run single-threaded, although multi-threaded execution is supported on Node.js 0.10+ from JXcore. Node.js is based on single-threaded execution, although Node.js uses multiple threads for file and network events.

Node.js can be compiled locally or downloaded as a pre-compiled binary. Applications are executed from the command line with the command: "node <application name>.js"

"invented" vs "created" vs "implemented"

Very different connotations. "Implemented" tends to downplay creativity, and invented really emphasizes it. Page runs the risk of copying positive or negative wording, as propagated by interested parties, if such distinctions are not made.88.159.78.20 (talk) 00:46, 29 April 2015 (UTC)

 Done Thank you for the note. --Ancheta Wis   (talk | contribs) 05:57, 29 April 2015 (UTC)

Merge with Io.js

I've merged Io.js with Node.js because it is a non-notable fork. Of course its probably gaining traction but nothing close to Node.js. Plus node is used by large companies and popular websites, making it highly notable. Io.js seems like a small project as of date, and deserves no independent article IMO. -- Wonderfl ^(reply) 05:58, 10 February 2015 (UTC)

I feel, Io.js project might not be good enough for a complete page, but Node.js, page doesn't need a section of Io.js, what do you say? -happyhardik — Preceding unsigned comment added by 117.196.46.62 (talk) 13:29, 21 May 2015 (UTC)

Excessive / intricate detail: remove 'alternatives'

I suggest we

• remove 'alternatives' section
• add link to Comparison of server-side JavaScript solutions to 'see also' section

Io.js is now nothing more than 'previous versions' of Node.js, not really an alternative.

JXcore, one of many JS server-side solutions, would then be covered in 'see also'.

'Other languages' seems highly specialised for a general audience.

I would also support removing the 'Tools' section, due to limited interest to a general audience, and the idea that wikipedia is not supposed to be a directory.

CDV 16:04, 13 January 2016 (UTC)

Trying to get rid of multiple issues

Hello!

This article has currently multiple issues:

• This article relies too much on references to primary sources. (September 2015)
• This article may contain an excessive amount of intricate detail that may only interest a specific audience. (August 2015)

I tried to get rid of these problems. Please check whether my version has improved it. Concerning the second issue, I proposed to move the technical features into a new article, which was rejected – perhaps because of having there only one source.

For those who do not know: Yes, this article is about Node.js, which can be compared to .NET and Java concerning usability and speed!--Sae1962 (talk) 13:12, 26 January 2016 (UTC)

It is not an improvement to replace primary sources (to an authoritative, albeit primary, source) with random half-understood scrapings from Quora! (or StackOverflow et al). If there isn't a good source (or an adequate one), then we don't get to say anything.

There is no comparison between Node and Java. None. You can compare JavaScript and Java, or you can compare Node and Java Servlets, or Servlets under Tomcat or such, but comparing Node (a framework) and Java (a language) is comparing apples and fish. Much of what is "interesting" about Node is at a much higher level than the JavaScript alone: not even just the framework (to compare clock cycles against Tomcat) but about the particular ways Node forces/encourages developers to work, such as the event-driven emphasis. You'd be better drawing comparisons (if you must) with JSF, not with raw Java. Viam Ferream (talk) 13:41, 26 January 2016 (UTC)

That wasn't an invitation to start adding "sources" from StackOverflow.

It is wrong (really wrong!) to say "Using relational databases with Node.js is difficult." Even the StackOverflow source doesn't even say that. Viam Ferream (talk) 14:34, 26 January 2016 (UTC)

"As the V8 engine is written in C, Node.js runs much faster than Perl, Python, or Ruby.VoidCanvas"

What does that even mean? Let alone "VoidCanvas" as a source (couldn't Quora do it?) SEO positioning in an easy Google search is not the same thing as WP:RS.

CPython (the default Python interpreter) is written in C. PyPy is written in RPython. So does that mean that Python interpreted by CPython is also going to be "much faster than Perl, Python, or Ruby" too? Yet PyPy is faster, as is rather the point to using it. The implementation language of a language platform means almost nothing for how fast the finished language runs! It's far more about what the language does, and how the platform does it, with a dose of how much run-time speed optimisation the developers have been able to give it.

Presenting flaky half truths like this to our readers does them no service at all, nor does dressing it up with "sources" like this. Viam Ferream (talk) 13:59, 26 January 2016 (UTC)

OK. The criticism of Node.js on the Web reads as if Node.js itself is a server environment. If I understood what you all write above, it would make sense only to compare V8 and .NET or V8 and Java EE. Is that correct? And what do you think about the equation Node.js = Runtime Environment + JavaScript Library?--Sae1962 (talk) 15:01, 26 January 2016 (UTC)

It's an interesting comparison to compare it with .NET, because .NET (a BIG problem with .NET) is already too much of a monolithic slab that implies adopting the whole ".NET way" all the way from server to application menus.

What's "Java EE" though? Almost no-one used Java EE as it was first defined by Sun. There's a lot of Java + Servlets + JSP out in the world, even now, but EJB never had anything like the same level of take up. Mostly though, J2EE didn't deliver what was needed and so "a Java web app" is a combination of the Sun-sourced stuff, like Servlets, together with other stacks on top of it, like Struts, JSF and a gazillion other pieces, all probably hosted under Apache / Tomcat / Catalina or something else that didn't come from Sun. Given that the interesting thing to discuss about Node is mostly the event and threading behaviours, you have to start looking for stacks that go high enough and low enough to make comparisons valid there. EE is only a skinny layer in the middle (Servlets don't even do routing, they just respond to methods that have already been mapped from URLs and methods).

Any comparisons drawn from Node to "the Java world" are thus unrealistic. They would have to qualify just what this "Java" context is (what other components have been included) and that means that they're then likely to be unrealistic for other equally valid Java contexts. Viam Ferream (talk) 15:13, 26 January 2016 (UTC)

So, you mean that the buzzwords used (like .NET, Java EE, Node.js) are not comparable at all. There is some similarity with natural languages, though. If you take the notion (or word) of religion, say, you can easily translate it to other languages. But when comparing these translations and how they are embedded in the respective cultures, they all differ and become hardly comparable.--Sae1962 (talk) 15:53, 26 January 2016 (UTC)

Comparisons are good. People like comparisons. They help to explain things.

That said, any comparisons added need to be relevant and to have some competent sourcing. What are the aspects of Node that an experienced Node user will see as both prominent and distinct from how other systems work? Who has written about this and is vaguely trustworthy. If something was implemented in C under the hood, that just doesn't matter. The real picture is so much bigger, the overall performance so much more complicated. Easy comparisons are rarely useful comparisons.

I'm all for blog sources. Really good geeks, writing about something they really understand, that's good stuff. _why_the_lucky_stiff or Dive Into Mark - that's the best stuff out there. Wikipedia hates it of course, because a bunch of bitter old eunuchs don't like anything that they didn't use themselves 20 years ago, so they say, "If it's not on paper, it's not valid". But on the other paw, StackOverflow... A bunch of random college kids who hardly understand it in the first place? We can't use that and we shouldn't use that. Viam Ferream (talk) 09:47, 27 January 2016 (UTC)

I agree with you. So, what we need is to agree in a list of reliable sources. Any URL not there could be contested. Or does this list already exist?--Sae1962 (talk) 11:00, 27 January 2016 (UTC)

Cons and pros

TL;DR version : Some partly-technical fellow created a section comparing Node.js with .NET and Java. This is an apples-to-oranges comparison. As a responsible expert on the subject (I wrote the well-sourced Overview section), I removed it and placed it here primarily because it is 90% incorrect and 100% unsourced. I suggest a new section be written comparing Node.js against Twisted, EventMachine and Vert.x. Anything else is an apples-to-oranges comparison. Good day.

Wonderfl ^(reply) 11:39, 27 January 2016 (UTC)

Solid work on curating this page, @Wonderfl:. What do you think of my proposal just above to remove the 'alternatives' & 'tools' sections? cdv (talk) 10:34, 28 January 2016 (UTC)

Agreed.

I'd lose or rewrite the tools section. Lists of unexplained links never work on wikipedia. They don't add much and they do draw spam. Even as a "further reading" list these don't work, because of the spam draw. Eclipse and VisStudio as links? What possible specific relevance do these generic tools have to Node? You might as well add ASCII as something that's overwhelmingly used by Node developers.

Alternatives is trickier. The content here is important. They're not "alternatives" though: maybe in one sense "things that are Node-like but are not Node", but not in the sense of "Things that you, the app developer, might choose to use instead of Node". Call them Forks, because that's what they are?

"§Other languages" wants to be promoted as a section, as it's not a sub-component of Alternatives, as io.js is. Viam Ferream (talk) 10:47, 28 January 2016 (UTC)

io.js is not longer a fork (as it's been merged in to Node.js) - it's simply [previous releases], which no longer seems worthy of a section of its own to me. I've no particular view on the importance of JXcore and the 'other languages', quite happy to leave them in if they have value... cdv (talk) 12:24, 28 January 2016 (UTC)

io.js was a fork and like cdrtools as I understand it, it was one spawned by license wrangling, not tech issues. I think it should stay here, in much this (maybe renamed) section, but shrunk down a bit and without the infobox. It was WP:Notable once, but there's no value in pushing it out to a separate article. It still has some relevance for the "Node's licensing approach has been questioned" aspect. We need to document it more as "an event in the history of Node", more than "a thing that you might use" or "a thing that was once big".

I don't know anything about JXcore, but it looks like a current and ongoing project to put Node onto a lightweight platform has some value to it. Not enough for its own article as yet (more adoption, more coverage in RS forst), but definitely worth including here. Viam Ferream (talk) 12:42, 28 January 2016 (UTC)

@Viam Ferream: - Visual Studio for example is particularly notable because its hard for anyone to imagine MS dabbling in FOSS projects. It also allows us to link to TypeScript which allows VS to be a premiere JS environment with strongly-typed compiling, unlike ASCII editors/notepads/IDEs that you mention. Visual Studio Code also has debugging support for Node.js, something not every text editor can do. (or not?) But you are somewhat right, in that the list is becoming a massive "share your favorite JS IDE" list, irrelevant since any notepad can work for JS. However IMO the tools that specifically support Node.js (such as VS+TypeScript+node.js headers) should be mentioned, and in a bit more detail too. I have only used a couple of these tools.

@CDV: - Thank you. I agree that most generic JS tools should be removed, but the tools that have hard-coded Node.js support should be mentioned, and in prose. The bulleted list style makes it a spam draw as Viam also noted.

Regarding the Alternatives section, I think its a mess. Firstly, proper alternatives like Twisted, EventMachine and Vert.x are not mentioned when they deserve a full-fledged comparison against Node. They are practical alternatives but all a bit older than Node, which is the "latest and greatest" server development framework (IMO). Secondly, Io.js might have been notable, but since it is dead, it needs to be trimmed (only exceptional points should be noted) and perhaps have its logo removed (far too attractive and large) or better yet the entire infobox. We need more prose everywhere. Perhaps Io.js can move into the History section since its only a minor historical event and has no more significance, and is definitely not an alternative to node (at least no longer).

Wonderfl ^(reply) 08:07, 29 January 2016 (UTC)

I've been WP:BOLD and merged Io.js into History (most of the points were already covered). Then, I added proper alternatives into the Alternatives section. Lastly, I added Edge.js which is very notable and had no mention. Regards Wonderfl ^(reply) 08:28, 29 January 2016 (UTC)

Nice work @Wonderfl:, that's much improved. I've had a go at converting the Tools section to prose and stripping it down to essentials; if I've lost anything of value, feel free to reinstate! cdv (talk) 13:56, 1 February 2016 (UTC)

@CDV: Good job! I added refs for whatever tools had articles regarding Node.js, and finally merged it into the Overview section under "Industry support". This was beneficial because "Tools" aren't a very big deal and the frameworks point was duplicated. Merging it allowed these two issues to be resolved nicely. Looks good as of now? Wonderfl ^(reply) 17:20, 1 February 2016 (UTC)

@Wonderfl: LGTM cdv (talk) 18:58, 1 February 2016 (UTC)

---

Lets go point by point:

• As V8 is written in C++ it runs faster than Perl...
  • How can anyone be sure? Link to speedtests done by reliable parties. Hearsay cannot be added.
• Easy to start with..
  • So is any other language
• For non-CPU-intensive applications, Node.js is out-of-the-box faster than other servers
  • Link to speedtests done by reliable parties. Hearsay cannot be added.
• It's possible to stream big files..
  • What is this rubbish? Any server allows this. Even Apache!
• JavaScript, the language Node.js uses, is actually more succinct in a few small ways..
  • Compared to what? TypeScript was invented specifically because JS was too "succinct" and lacked type information! C# added the "var" keyword with the DLR allowing JS-style code to work on .NET? Wanna do a C# vs JS comparison instead?
• Node.js can handle thousands of concurrent connections with a minimal overhead..
  • So does any other framework
• Node.js has an ever-growing large community..
  • what? is it a plant? ever growing?
• Node.js is not designed for CPU-intensive tasks and will perform bad, if the application does execute such..
  • says who? I've been processing binary for years!
• Node.js is not single-threaded; for a time-consuming process, like an I/O-bound operation... one can easily create this exact pattern in other platforms, like .NET....
  • Oh really, then why do you think Node.js was invented in the first place? If you can roll your own, a better node.js, then why haven't you done it already? Remember that almost everything that a framework provides can be redone manually by hand in another platform. Your point is meaningless
• Node.js must parse to and from JSON...
  • What rubbish, I've been working with Buffers (binary data) for years. Have you even read the Node.js documentation?
• The node packaged module is included and is becoming stronger..
  • "becoming stronger"?? and FYI its the Node Package Manager, not "packed module"
• Uses easy-to-learn JavaScript as language..
  • Yes, so is C#. So is Swift. JS is easy compared to what?
• Using JavaScript on both on the client- and server-side reduces the impedance mismatch..
  • impedance mismatch? speak in English dude, don't use technical peacock terms to obscure a poor point
• Using just simple JavaScript, Node.js is not something new for programmers..
  • excuse me? "is not something new for programmers"? which kind of programmers?
• Ending up always with a callback results in a huge number of nested callbacks..
  • the entire design of the Node.js syntax revolves around callbacks! how can that be an issue? use .NET or Java if you don't like callbacks!
• Node.js does not provide scalability..
  • Bullshit! Node.js is used by many large web apps including LinkedIn and so on... they don't scale? Says who?
• Static Java with Netty and Play is faster..
  • So is a server application written in x64 assembly and hand optimized

Anyways I'm too tired to go on with this. I've demonstrated quite reasonably that the entire section is rubbish. I appreciate folks that bring useful and technically accurate advice to the populace via Wikipedia. But a bunch of hearsay and opinion disguised as a comparison between frameworks is totally intolerable. If anyone wants to rewrite this, at least use "expert opinion" from Stack Overflow or some other crowd-sourced website rather than using your own limited and biased brain. Wonderfl ^(reply) 11:24, 27 January 2016 (UTC)

Cons and pros

Node.js does not have a better performance than matured platforms like .NET.

Pros

• As the V8 engine is written in C, Node.js runs much faster than Perl, Python, or Ruby.
• Client-side and server-side code can be shared.
• Easy to make end-to-end development, as both frontend and backend use JavaScript
• Easy to start with, and having the possibility to do complex things.
• For non-CPU-intensive applications, Node.js is out-of-the-box faster than other servers.
• It's possible to stream big files.
• JavaScript, the language Node.js uses, is actually more succinct in a few small ways with the "feature" of not requiring strict variable types.
• Node.js can handle thousands of concurrent connections with a minimal overhead.
• Node.js has an ever-growing large community.
• Node.js is not designed for CPU-intensive tasks and will perform bad, if the application does execute such.
• Node.js is not single-threaded; for a time-consuming process, like an I/O-bound operation, the single thread to which the developer has access only delegates the task to a thread in V8 that is in a pool of underlying C++ threads. Although this is a very good, scalable, highly-available way to write code, one can easily create this exact pattern in other platforms, like .NET.
• Node.js must parse to and from JSON, like .NET must serialize to and from JSON to interact with .NET objects, but parsing is much cheaper in Node.js concerning overhead than serializing in .NET.
• The node packaged module is included and is becoming stronger
• Uses easy-to-learn JavaScript as language.
• Using JavaScript on both on the client- and server-side reduces the impedance mismatch between the two programming environments that can communicate data structures via JSON. Duplicate form validation code can be shared between server and client, etc.
• Using just simple JavaScript, Node.js is not something new for programmers, so JavaScript developers don’t have to put much extra effort to learn Node.js.

Cons

• .NET is more versatile and powerful than Node.js.
• Any CPU-intensive code will block the entire system, making the application unresponsive.
• Ending up always with a callback results in a huge number of nested callbacks.
• Java has more mature development tools than JavaScript/Node.js.
• Node.js does not provide scalability.
• Static Java with Netty and Play is faster.

References

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Node.js. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive http://web.archive.org/web/20160203083254/http://definitelytyped.org/ to http://definitelytyped.org/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 21:36, 24 June 2016 (UTC)

tagged for fact

I tagged the last sentence in the threading section as needing a reference because it doesn't sound correctly worded to me and if it is correct then I'd like to read more detail about it. RJFJR (talk) 13:34, 13 March 2017 (UTC)

Maintenance and rating of JavaScript articles

Concerning editing and maintaining JavaScript-related articles...

Collaboration...

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Where to list JavaScript articles

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

User scripts

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:12, 12 April 2017 (UTC)

Who's Ryan Lewis?

How is it that he is not mentioned in the article body? Whaa? (talk) 20:26, 22 April 2017 (UTC)

runtime system??

This article does a poor job of explaining node.js to those unfamiliar with it. It suggests that node.js is a system programming language but that the event-loop and asysnch-io are part of the runtime system (ie the component that performs runtime type-checking, stack management, stack traces). This makes no sense. All languages I know provide an event-loop as an optional component. An event loop baked into the node.js runtime seems implausible because it prevents lots of general programming including REPLs. File I/O is implemented by calling out to an external runtime system (the kernel, or libc) or as a wrapper library to these externals. But that the default I/O is asynchronous... I think I'm going to need some examples. There's a discontinuity in the description of what node.js can do, and how it actually works. — Preceding unsigned comment added by 100.1.10.152 (talk) 04:14, 23 July 2017 (UTC)

Use of node.js for developing desktop applications

I noticed that this article doesn't mention the use of node.js in desktop applications (using appjs, node-webkit, and other frameworks). Is this notable enough to be included in this article? Jarble (talk)

we can add the following. Worth the citation since we have apps made using Electron being frequent now Certified WikiDoge (talk) 11:18, 11 August 2017 (UTC)

References