Hot answers tagged

70

1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is. At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular: if two tasks try to access a variable ...


46

First of all, I agree with JUST MY correct OPINION's answer regarding learning Erlang. It's a mostly functional language (although concurrency plays a big role), and all of its features were added to go towards fault-tolerance and robustness, which is not exactly the same design goals as Javascript in the first place. Second of all, leaving Node.js to get ...


44

It's a bit tough to say because these words are not well-defined. In common parlance, I think it's a bit atypical to call Node.js a framework, sure, but I'd have a hard time arguing as to why exactly it is not. This all gets dicey, and I often see really poor uses of language, so I'll be explicit and start from the bottom JavaScript is a computer language, ...


38

Erlang isn't complicated to learn, it's just alien to the mindset that the Chambers Constant (99.44%) of coders have learnt as the way programming works. The problem you're facing are likely just conceptual disorientation rather than actual complexity. Here are some of the alien features of Erlang that are going to bite a typical programmer: Erlang is a (...


35

JavaScript certification is called github. It's called write modules, maintain modules, and share modules with the community, build popularity, etc. As a JavaScript employer I couldn't care less what certification you have, I care about either examples of github modules showing quality code or live websites/web applications show high quality code.


35

You literally cannot prevent users from accessing and modifying content that you are sending them. You have no control over the browser, or which browser they use, or whether they are in fact downloading your source code via a browser. You are executing your code on another person's device. You should not and cannot assume anything about the integrity of ...


33

While that concept can indeed be implemented in many languages (and as dodgy_coder mentioned, it has been implemented in Ruby and Python at least), it's not quite as trivial as you state. True, Java has non-blocking IO APIs. So you can do raw disk/network IO in a non-blocking way. However every API that somehow wraps or handles IO needs to be implemented in ...


27

The nice thing about callbacks is there's no global state there, and passing parameters to them is trivial. If you have a function download(URL, callback: (FileData)->void) then you can know that's a self-contained higher-order function which essentially lets you construct a "grab this and do that" function. You can be sure your code flow is exactly as ...


23

You can't. One of the fundamental rules of computing: you can't trust the client. Whatever clever scheme you think of, I can get round it if I am in control of the client.


22

Most of the questions you ask are not answerable without context, and are more or less moot given management has already made the choice for you... unless you are asking 'should I quit and find a new job in the face of all this change?' If your going to tough it out I recommend you read this this post on the topic: How To Survive a Ground-Up Rewrite Without ...


22

I've run into some difficulties thus far I'd like to document here. How do you handle reconnect logic? This is a hard problem and an especially hard problem in designing and implementing a message queue. Messages must be able to queue up somewhere when consumers are offline, so a simple pub-sub is not strong enough, and consumers need to reconnect in a ...


20

Of course any CPU bound work is going to utilize the CPU. It's going to block the CPU in whatever language or framework you write it in. Node.js is great for when you have I/O bound work, not CPU bound. I wouldn't do heavy lifting in Node, though it can be done. Node.js solves real problems, not fictional or imagined ones like fibonacci number servers. It's ...


20

Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. source Node is a runtime or environment. It is not a framework. People (I feel) often get this wrong because frameworks like express are ubiquitous with node. more reading on runtimes vs frameworks if you are interested.


19

Probably the main reason is that it uses JavaScript to write server-side components for things such as web servers, web applications or web services. This unifies the traditional front end (client-side) development language JavaScript with the server-side language. You're right - the fact it is non-blocking, using the reactor pattern is not unique - it has ...


18

There is two important things that make Node.js different to existing server-side frameworks, asynchronous events and the use of JavaScript as a programming language. Asynchronous Events While most of the existing server side frameworks use a synchronous architecture, Node.js uses an asynchronous architecture, which JavaScript can handle well. This means ...


17

When Node.js is described as "non-blocking", that specifically means that its IO is non-blocking. Node uses libuv to handle its IO in a platform-agnostic way. On Windows, it uses IO completion ports, on Unix, it uses epoll/kqueue/select/etc. So, it makes a non-blocking IO request (which may have a background thread monitoring, but this is never exposed to ...


17

In the context of web applications, we call the server stateful if it maintains transient state in memory, rather than storing any data externally (e.g. in a database). Stateful applications have a number of problems, for example: you can't have more than one server running without pinning sessions to a particular server the state is lost when the server ...


16

It's a front-end, back-end application, with a REST interface in between. You already have full separation. My vote is for option # 3. You seem worried about configuration, but that's kinda the whole point. Configuration allows you to have full separation without requiring tightly-coupled code bindings. If you're worried about CORS, put everything on one ...


16

Just guessing here to demonstrate a problem in your approach. I can't test it against the real implementation as there is no link anywhere... I'd say it is because invariants are not always expressed by the value of one variable, and 'one variable' is not sufficient to be the scope of a lock in the general case. For example, imagine we have an invariant ...


15

A decade or so ago Brendan Eich (the inventor of JavaScript) wrote an essay called Threads Suck, which is definitely one of the few canonical documents of JavaScript's design mythology. Whether it is correct is another question, but I think it had a big influence on how the JavaScript community thinks about concurrency.


15

All three properties are populated from different sources: req.query comes from query parameters in the URL such as http://foo.com/somePath?name=ted where req.query.name === "ted". req.params comes from path segments of the URL that match a parameter in the route definition such a /song/:songid. So, with a route using that designation and a URL such as /...


14

Running several web server processes in parallel is not a problem at all, people do it all the time. However, since only one process can ever listen on any given port, they can't both run on port 80 directly, so you'll have to dispatch somehow. An easy solution is to run the Node.js application on a custom port (anything above 1024 should be fair game, but ...


13

is there any good reason to avoid Node.js for traditional web apps Yes, if you have N years in web platform X then clearly you can developer an application in platform X faster. If you want to do Y and platform X has a pre-made solution Y that does X then do so. All the generic reasons of why you should use one platform over another. the sort of CRUD ...


13

In general, any function that does networking or uses timers to do things over a period of time will be asynchronous. If the function takes a callback, you can look at what the callback is used for and usually it will be obvious whether is is asynchronous or not. If the function does not offer a callback, then it has no way of communicating asynchronous ...


13

It's particularly strong at handling a ton of file I/O and I would expect it to handle a ton of network communication well too. It seems particularly popular for socket-driven apps. The important thing to keep in mind is that if your needs aren't met by existing libraries (there are many) you may need to dive into some C which can be bound to JS commands. ...


13

There is little use of actually doing an HTTP request. When the underlying application processes the GET request from your example, it probably calls the business layer which does some input checking, and then calls the data access layer which retrieves the puppy. In a similar way, the POST request could, instead of doing an additional GET, simply ask the ...


11

I'm now looking at node.js and it's performance implications (I'm addicted to speed), but I haven't delved into it all that much. Profile, profile, profile. That's the only way to know that your speedups are having the proper affect. You can guess that it's fast enough. But most people like to prematurely optimize. That's worse than playing with yourself ...


11

We will have about 200 computers (most on the same network) that will each send, via HTTP POST, around 5000 requests/day. With each request containing about 300 bytes of data. That's about 10 req/s. So it's clear that you don't need to switch. Real life benefits of switching (besides getting valuable experience)? Well, as you said, you're hosting on ...


11

Since you can pass functions as parameters, it is common to pass a "callback" function to these sorts of functions. So, for example, you may have a "read" function that looks like this: function getUser(userId, callback) { var mydbAPI = something; var myQuery = somethingElse; mydbAPI.getUser(myQuery, function(data) { //parse data a little here: ...


11

You're mixing apples and oranges, kind of. Servlets (or inheriting from HttpServlet) let you access HTTP request parameters and respond with something, via (or on top of) an existing HTTP server implementation. Although using Javascript as the language, Node.js is at a lower level than that. It starts from actually implementing the HTTP server. You can go ...


Only top voted, non community-wiki answers of a minimum length are eligible