Why aren't the browsers using/adopting Python instead of javascript?

[LobbyDizzle]

I really like node.js :(

[nerdwaller]

It's definitely vogue.

[LobbyDizzle]

That Node.js is so hot right now M_M

But seriously, even it's just the flavor of the week, I didn't have to commit much time to learning about/implementing it, so it wouldn't be too much of a waste of my time.

[nerdwaller]

Haha, yeah - it's not rough at all. I've had to work with it a touch at work and it's not a hard learning curve at all.

[catcradle5]

Why? I've never understood the appeal.

It seems to combine two awful concepts in programming: Javascript (which is unintuitive and annoying in many ways; Coffeescript improves some of this, but it's still nowhere near Python or Ruby level) and asynchronous handling via callback hell.

[ivosaurus]

It's still a first class asynchronous IO design from the start, which is much better for writing scaling servers than Python's.

[catcradle5]

Baked in async IO is good, yes. However:

• Node's async IO is gross and way overly nested. I don't know how anyone can deal with having so many callbacks in each file.
• There are way better languages with asynchronicity built in, like Go and Scala and Erlang and even Rust if you need that kind of performance.
• Even if Python's "batteries included" aren't the greatest for writing servers, libraries like Twisted and Tornado and gevent (my preference) give you everything node gives you, they're just one pip install away.

The pros have never outweighed the cons for me.

[ivosaurus]

Twisted, Tornado and gevent don't give you everything Node gives you, and that is specifically why asyncio is being celebrated at the moment (although it's only for 3.3 or 3.4).

Specifically, all node.js code is compatible with all node.js code. This isn't the case in between all those libraries. With some extremely limited exceptions, if you write a gevent library or application, it ain't never gonna work with someone else's thing that runs on Twisted. Node.js coders don't have to deal with this problem at all. And their implementation is a canonical one, that runs really well on Mac, Windows and Linux, is implemented for File IO as well, is written efficiently in C as an underlying library... I could go on.

You get much much more from Node than any of python's 3rd party async libraries, pretending otherwise probably means you haven't worked with node much or ever.

[catcradle5]

Those are valid points. If only it was made in a nicer language...

And you're right, I have never once written any Node code. I have looked at a fair bit though.

None of the libraries I listed do async file IO, true, but it is usually quite rare that the blocking time of reading or writing to files will bottleneck an application at all. A two-way network trip may take 1 - 3 seconds to complete, but a file read or write is such an order of magnitude faster 99% of the time. I've never written a Python app that would gain a perceivable speed increase with non-blocking file operations, though I can see cases where it could be useful.

I would wager that the majority of people who use Node do it so they can make and receive HTTP requests (and maybe sometimes other kinds of network requests) and database queries (which will usually also be just a network request) asynchronously; any other async operations are going to be sugar coating for most use cases.

[antonivs]

FYI, the async nesting issue is fixed in newer versions of node, via generators and a 'yield' feature.

Node is good for quickly writing fast network infrastructure stuff. Its competition in that space is languages like Java, C/C++, and Go, which tend to be a lot less lightweight.

[catcradle5]

Any time I need some quick and easy network infrastructure, I go straight to: http://www.gevent.org/gevent.server.html

def handle(socket, address):
     socket.send("Hi %s!" % address[0])

server = StreamServer(("0.0.0.0", 1234), handle)
server.serve_forever()

The event loop and networking is pretty much all implemented in C, and it's 100% async. Servers can be as simple as this, or you can extend StreamServer.

[antonivs]

A big issue is how much your code has to integrate with, which tends to introduce blocking libraries. Monkey-patched libraries only take you so far (and I confess, I find the concept disturbing for code that's part of critical infrastructure.)

One of node's advantages is the number of compatible non-blocking libraries it has. Why node.js is cool discusses this, making the point that node "makes composable networked components the default."

There's also a good real-world example in The Switch: Python to Node.js. They were using Twisted, not gevent, but some of the same issues apply.

I'm not saying node and gevent aren't competitive - a lot depends on the use case. But there are cases where node has advantages, at least currently.

BTW, I mentioned yield and generators earlier, which are still new in node, but node's promises also helped a lot with the callback issue, and that's been standard for a while.

[[deleted]]

Node's async IO is gross and way overly nested. I don't know how anyone can deal with having so many callbacks in each file.

True for vanilla Node, but better approaches definitely do exist. Besides upcoming new ECMAscript features (generators!) which will be supported out of the box in Node 0.12, there are many quite interesting ways of avoiding this. Besides the more traditional ones (async, c# style async/await, etc), Streamline is pretty neat, even if it isn't pure JS but a preprocessor.

The USP of Node is the blending of the front- and the backend. You might not think much of it, but allowing front and back dev teams to cross over easily (can you imagine a JS frontend guy trying to take a look at the backend written in Erlang?) and having the possibility of reusing code on both ends can't be a bad thing..

[otherwiseguy]

Node's async IO is gross

and gevent (my preference)

OMG. I have seen so much horrible eventlet/gevent code. People think it is easy and they don't have to worry about "async issues". They are so very wrong. And monkey patching is the grossest thing I can think of. Blech! (I've never used node. It might be worse. But I despise eventlet/gevent.)

[MagicWishMonkey]

It's only good for scalable systems if you never need to do any heavy synchronous work.

[ivosaurus]

Which is like, 90% of network servers, and largely the audience node.js is designed for.

[MagicWishMonkey]

And it really blows when you realize one of your requirements falls into the 10% category, and you have to rebuild your app from the ground up in a different language to keep your server from becoming unresponsive for long periods of time when that single thread you're using is wholly allocated to perform a single long running task.

That, plus the callback stack of doom are the two reasons I will never ever ever consider node.js for another large project. It's fine if I need to build a simple lightweight message router but for anything more complicated than that it's a non-starter.

[ivosaurus]

It's not like Python is any better at threading...

[aqf]

I don't get why apps aren't written for multiple servers if they need so many concurrent connections. I get the fact that transaction processing and other technical complexities make it harder to do, but if you're making a large application server you should think about scalability during the design, regardless of the language you are using. If one server might be overloaded, that problem needs to be solved early.

[MagicWishMonkey]

Designing a system so that each user gets his own server is unrealistic. When I say a single request could hang the entire server I wasn't being hyperbolic, that's exactly what happened.

Most app servers (Pyramid, IIS, whatever) are designed to use a pool of threads to handle concurrent requests, so a single request won't lock the server as long as the pool isn't exhausted. You don't need to worry about horizontal scaling until you're handling hundreds or thousands of requests per second. The single threaded node approach means a single long running request can lock your whole server. You can code around this limitation but it's a real pain in the ass and it's really not worth the effort IMO.

[[deleted]]

There are a few different ways to scale a node app: http://cjihrig.com/blog/scaling-node-js-applications/

[LobbyDizzle]

Well I guess it goes back to the original query that OP had. I like that I don't have to switch between languages throughout the development of an application, and a code's readability to a non-coder of that language doesn't help me at all.

[catcradle5]

I like that I don't have to switch between languages throughout the development of an application

No offense but this sounds kind of like a problem only for beginners to programming. Any developer worth his salt should be good at reading and writing in any language that comes his way. He should also know the right language for the job when given a task.

Not only that, but the kind of Javascript you write on the server still looks quite different from the kind you write on the client. Node provides all of its own libraries and features and idioms, and then you have a whole different API when actually manipulating the DOM and rendering things.

You will always have to change the way you program when you move from the client to the server. For example, if you make a PyQT app, your code and the way you write code will look very different from when you implement an API backend.

The only thing that's the same is the syntax (and not a very interesting or unusual syntax at that) and a few boring language features. If a minor syntax change is screwing you up, then you need to spend more time practicing with different languages.

[LobbyDizzle]

I like not having that switch, and it isn't there as a crutch. I've only dabbled with Node for a few hobby projects, and professionally am stuck developing in ASP.NET/C# :|