[timr]

There's literally only one reason to do it in Javascript: you want to use Javascript. There are dozens of reasons why it's a terrible idea: unfortunate memory consumption, abysmal performance, poor abstractions, bad library support, and so on. Tensorflow in Python isn't exactly a stellar choice for performance, but at least you gain flexibility and nice abstractions and good high-performance math/stats library support. Go with JS, and you're getting none of that.

"Many companies and projects have their entire server-side stack in JavaScript and Node.js, and often they want to simply make a prediction through a model."

Right. So this is "we don't want to use another language". Acknowledged.

"Privacy. You can make predictions locally, or send embeddings back to a server without the raw data ever leaving a client."

If calling out to a binary is a security problem for you, you have bigger problems than choice of language. Also, of course, you don't need tensorflow to convert your top-secret data into an input vector that you can send somewhere (seriously: it does not help with this problem).

Your third and fourth points -- flexibility and interactivity -- are indeed why people use Python vs C++ (even though it's more difficult and painful to get decent performance out of TF with that approach). So again, this boils down to "I don't want to use Python and I'd prefer to use JS instead."

"No servers for applications. Making predictions in TensorFlow on a server can be expensive in the long run. Hosting static weights on a server is much much cheaper."

You're contradicting yourself with this point. Servers are expensive so hosting static weights on a server is cheaper? I have no idea what this means.

[williamdclt]

> So this is "we don't want to use another language".

Yup, which is a perfectly valid reason.

> If calling out to a binary is a security problem for you

You miss the point. The security problem is sending the raw data from the client to the server.

> So again, this boils down to "I don't want to use Python and I'd prefer to use JS instead."

Which once again, is a perfectly valid reason

> Servers are expensive so hosting static weights on a server is cheaper?

No, CPU/GPU intensive tasks on a server is expensive but storing a few static weights is cheap.

[timr]

"You miss the point. The security problem is sending the raw data from the client to the server."

So don't do that. If you can run tensorflow on your device, you can call out to a local process.

If you want to use JS to do everything, fine. But that's not a good reason. It's just a reason.

[zeroxfe]

> So don't do that. If you can run tensorflow on your device, you can call out to a local process.

Not from a webapp (without jumping through a dozen other hoops.) With tensorflow.js, you can do (for example) pose estimation, or face detection, or audio recognition, right in the browser without sending data to a remote server.

> But that's not a good reason. It's just a reason.

Yes, of course it's a reason. The point is that it can be a good reason in many cases.

[timr]

So now we're down to "I want to run a neural network exclusively in the browser" as the primary reason you'd want to use this.

OK, fine. That's a niche use-case for a domain where scale and performance matter so much that we're building specialized hardware to support it. For 99.99% of developers, they would be better advised to find another way to solve their problem using more conventional tools.

There was a guy who built a life-sized house out of Lego once. It was a cool trick, but the difference between him and "modern Javascript" developers is that he didn't try to make anyone live in the house.

[halflings]

How can you run Python tensorflow locally? We're talking about web apps here.

Try to understand what is at play here. It's not all about raw performance, there are many more important things to consider that GP explained extensively.

[quadrature]

I think you're conflating privacy and security. Serving the model on the client side means that the server is never aware of who put the inputs in.

Also he isn't contradicting himself, serving static data off a CDN or server is a lot easier and a lot less expensive than having a cluster setup to do inference.