That's totally exciting! Thanks to the author for enriching the ML ecosystem in JavaScript :)
I didn't explore the full API yet, but already seeing the plotting functionality for functions is a tremendous win for ML in JavaScript.
In case anyone is interested in doing ML in JS in 2018, there exists a larger article which I wrote a couple of weeks ago that tries to convey the state of the art of Machine Learning in JavaScript. [0]
If I had heard someone talking about ML in Javascript a few years ago I would think it was a joke, probably because my professors seem to love to make fun of javascript, PHP.
It binds directly to the TensorFlow C API, if you run it in NodeJS, which is awesome. I get tired of having to setup a python env anytime I want to play around with ML.
Setting up a node env is arguably easier. An installer from the NodeJS downloads page includes both the Node runtime and NPM. One executable to get started.
Python, on the other hand, requires a python installer, then a pip or conda installation script. Not to mention python vs python3 decisions.
There's no python vs python3 decision to make. There's no (sane) reason to pick Python 2 in 2018 for new projects.
Conda installer comes with Python prepackaged. So it's really a single exe and one CMD to get a Tensorflow env setup. And, of course, you have access to numpy, pandas, jupyter, PIL ...
Yes, npm installs libraries locally so it avoids the need for something like virtualenv in the first place. Coming from Python, that immediately struck me as a better approach to package management.
You say this, but coremltools (convert from industry standard to Apple's ML framework) initially only supported python 2, so it was annoying to work with some code in Python 2 and some in 3.5.
Conda is like pip, but focused only on the sciences/data stuff. Pip has everything that Conda has and more as it's the standard packaging solution for Python.
Conda is more like pipenv in that it does both package management and environment/version management. And while it's true that not every python package is in conda, that vast majority are and conda and pip play nicely together if you want to use pip to install some packages.
Also conda can be used to install both surrounding tooling (like gcc and make, super useful on Windows) and, in many cases, build dependencies and necessary C libraries. Something pip doesn't handle. Doing for example "pip install gdal" will very likely leave you chasing down third party dependencies, while doing "conda install gdal" will just work.
Finally, conda has recently added R support. So you can now manage your R packages and environments with the same tools as python. Super handy if you have project that uses both R and python.
If you're happy with Python, great. But the market for something like this can be so much bigger.
Let's say you already have a NodeJS service. This reducers the friction to add some ML into the mix to basically zero. Install the optional propel_linux_gpu package, throw it on a GPU instance on AWS and call it a day.
ML right now is still mostly the domain of the tech giants and researchers, efforts like these will serve to make it an everyday component of software stacks everywhere.
I don't know what is the best practice. `pip` `virtualenv` `pipenv` `conda`?
NodeJS has `npm` or `yarn`, and they basically do and setup the same thing. You can switch between the two without headache. As a new user (or one who has tried on multiple attempts to get into it), python is hard to start.
I agree that JS is king in client side from PWA, desktop and native (with react), but also in async/API/distributed architecture. From a web server point of view, it took a large share of what usually went to Rails or PHP. It is a trend here to stay.
JS is also the largest community of devs, with 12M people very well versed in UX and ergonomics, something ML desperately needs to deploy faster.
Finally JS is a fast moving and innovative language due to many factors, from the fact we have several implementations, a light process for the tc39, transpilers, typescript/flow and wasm... What JS lacks from a syntax point of view may be adopted in months.
Agreed. Scientific computing has centered on two languages for well over a decade. I don’t think JavaScript is going to dethrone python as the interpreted language of choice because it can now push computation to the GPU via a well designed API.
We JS folks just need 1 good deep-learning system in JS. I really want that system to be propel as it leverages the work that has gone in on tensorflow. Let that piece fall into place, and just watch as the last bastion of python gets overrun.
>>...watch as the last bastion of python gets overrun
That is a naive point of view. The python community has been growing for decades [1]. Even if it is not growing as fast as javascript community, the growth is sustainable, and probably won't slow until the companies that rely on it for core parts of their infrastructure are gone (that could be 5 decades). Google, youtube, instagram, and countless other enormous corporations with trillions of dollars in combined market cap are dependent on it. Python isn't going anywhere.
> Pramod: Yeah, I like the programming model of Go. Using goroutines is so much easy and fun. In fact, we are using at work for building a distributed application.
> Ryan: Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go. That said, I think Node’s non-blocking paradigm worked out well for JavaScript, where you don’t have threads. And I think that a lot of the problems with kind of the call-back soup problem, where you have to jump into many anonymous functions to complete what you’re doing has been alleviated these days, with the async keyword, the async feature that’s in Javascript now.
> So, kind of the newer versions of Javascript has made this easier. That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever.
> Yeah. I think where Node has shined, weirdly, on the client side. So, doing kind of scripting around building websites. So, Browserify, for example. Kind of bundles up client-side Javascript. So, you can have all this server-side processing of client-side Javascript. And then, you know, maybe small servers to… maybe little development servers, and here and there, maybe some real servers serving live traffic. Node can be useful, or it can be the right choice for it. But if you’re building a massively distributed DNS server, I would not choose Node
this project does not work out of the box via npm install. seems like you have to get all babel.js with it and maybe use a typescript executor like ts-node
ES2015 imports took javascript back to 2008, before node and npm made it awesome.
use NPM and require if you are building tools for other people, that way they can implement your work without adding compilers and obscure configurations to their build. don't nobody want to use be forced to use alternative and backwards incompatible technology
Although propel itself is written in typescript, supporting users that want to write javascript is an explicit design goal.
The npm package contains "vanilla" javascript that targets node.js 8.x and later.
This could a fun way to learn ML using just your browser. I'm still skeptic about the performance but for prototyping it could be viable.
One thing bothering me about reading the API is the inconsistent way of adding semicolons. Not an important thing I'm sure and as my personal opinion I'd much rather have the examples without them. To me they are just waste of time. Also it makes the code look more like Python.
I found [this pull request] that adds language recommending the use of semicolons, but no proposals to require semicolons or to remove Automatic Semicolon Insertion.
Removing ASI from ECMAScript would break backwards compatibility - modern JS engines couldn't run scripts that use ASI which would break a lot of websites that are alread deployed. ECMA will add features that won't run in old engines (older V8 can't parse arrow functions) but they won't add/remove/change features that break existing behavior.
Today there are code patterns where ASI is ambiguous, or at-least hard for a developer to grok. TC39 is warning developers that new language features will not be designed for ASI and might have confusing behavior if those new features are used without semicolons.
I guess it's still work in progress, but they are probably aiming to achieve something in the direction of the scientific Python stack (i.e. Jupyter, TensorFlow and the like). Maybe starting with a subset of methods useful in ML.
It will be interesting to see how this scientific JS toolchain evolves. Would be fun to get a more feature-complete Propel ML working with Mike Bostock's Observable project:
> achieve something in the direction of the scientific Python stack (i.e. Jupyter, TensorFlow and the like).
Seems to be quite far away. IIRC, there are a lot of immature, scattered math libs for JS.
Most of the ML libs I've seen are proof-of-concept, like brain.js or synapse. Those libs seem to implement basic perceptrons and other textbook examples, but not much else.
Wonder if JS notebook environments like this one, Observable and runkit.com will eventually all consolidate and (hopefully) integrate with Jupyter Notebook / Lab
I enjoy machine learning and I'm interested in learning Javascript, so this seems really interesting. That said, what would be a good way to build some Javascript experience that would be useful for something like this?
I didn't explore the full API yet, but already seeing the plotting functionality for functions is a tremendous win for ML in JavaScript.
In case anyone is interested in doing ML in JS in 2018, there exists a larger article which I wrote a couple of weeks ago that tries to convey the state of the art of Machine Learning in JavaScript. [0]
- [0] https://www.robinwieruch.de/machine-learning-javascript-web-...