 All right, the survivor is awesome. Welcome to this talk. I'm Athen Reigns. And what I'm going to talk to you about today is math, numeric computing, and JavaScript, a nice weighty topic before you go home, right? And just so I can get a kind of feel for the room, I need to do a quick little survey. How many people here have done what they think to be numeric computing? That can be like clustering, statistical analysis, data analysis, just a quick show of hands, a timid show of hands. All right, how many people have used R? Excellent. Python, MATLAB, oh, Mathematica. Any Mathematica fans? How about Julia? How many people have used Julia? One brave soul. Awesome. And then how many people have used JavaScript for anything at any time? Everyone. But how many of you have actually used JavaScript for numeric computing? Oh, yeah? OK, awesome. All right, cool. So this talk is going to be a bit of a roller coaster. It's going to be an emotional journey, OK? It will be. So I mean, you guys are familiar with different languages. You're familiar with JavaScript. So what I'm going to tell you is going to be like, ah, oh, ah, oh, no, that's not going to really work. So I want to try to provide some light in terms of if you've ever thought about numeric computing in JavaScript, like how to approach it, what to avoid, the pitfalls, et cetera. Because if you're doing data visualization or you want to do some analysis, or maybe you just went a little bit of machine learning in your application, there are some things you need to be aware of and things that you need to look for in different libraries. So the overview is, first, I'm going to motivate a little bit like, well, why should you care about JavaScript in the first place? And then I'm going to talk about the state of JavaScript, in particular, the state of math in JavaScript. And then I'll talk about the state of the ecosystem. I'll talk about a project that I'm working on that's helping to drive this conversation forward. And then I'll talk about the future and how you can be a part of the JavaScript computing revolution. So without further ado, let's talk about JavaScript, everyone's favorite language. And whether you like it or not, like JavaScript is the capital T-H-E language of the web. And as Mike Bostuck was talking about, it is how you do things in a web standards way right now. And it's how you do things if you want to be able to distribute your application to anyone in the world, whether that's through desktop, mobile, or through the web browser. And depending on your bent, there are some things that are not so great about JavaScript. And then depending on your bent, there are some good things about JavaScript, using a fairly polarizing example. But when people think about numeric computing, they typically think about Matlab, or Python, Julia or Mathematica. They never really think about JavaScript. And we should ask ourselves, why is that? Why do people not really consider it? Is there something inherent about the language for why you can't do numeric computing on JavaScript? Or is it maybe just a historical accident? So let's investigate some of the reasons why people say, oh, I don't want to use JavaScript for numeric computing, for any kind of number crunching. First is that they might say, well, it's dynamically compiled. Maybe these are people from a C, C++, four-term background. But the reality is that many other numeric computing languages, like R and Python, are dynamically compiled, right? Or they say, well, there's no 64-bit integers. I care about my dollars and cents. Well, neither does R. R doesn't have 64-bit integers. You have to use an outside package for this. Or they say, well, there's no native big end, big number support. Well, in R, you need to use a package. In Matlab, you need to use a toolbox. So in these other numeric computing languages, you don't have these features. They also say, well, it's single-threaded. So is R, right? Or they say, well, what about performance? JavaScript is really slow, isn't it? And that may have been true back in the early 2000s and 90s, but that's no longer the case anymore, especially after the browser wars in the late 2000s, where browser vendors competed to really drive performance forward on the web. And so now I've done the benchmarks. I can tell you without a shadow of a doubt that JavaScript as a dynamically compiled scripting language is faster than R and Python. Most people don't realize that, but it's a fast language for doing just regular computations. And then finally, they say, well, there's no C, C++, and fortune bindings, because the secret behind Python, R, and Julia, et cetera, even Matlab, is that they're just wrappers around older libraries from 20 to 30 years ago. They integrate with, like, BLAS or LAPAC. That's where a lot of the performance comes in for linear algebra and high-performance computing. They just provide some external APIs. And the thing about with JavaScript is that, well, in the past, yeah, everything ran in the web browser, so you couldn't have, like, couldn't interface with C and C++, but given the rise of Node.js and the ability to write Node.js native add-ons, you can easily tie into these BLAS libraries and get high performance in American computing and JavaScript now. And especially with web standards coming on board, like WebAssembly, this means that you can run native code, C, C++, in a web browser with near-native performance. So what was true in the past is no longer really true now. But there are two more substantive issues that people give. So all those reasons I just listed are they're not technical barriers for why you can't do numeric computing on JavaScript, right? There's no reason why you might choose R just as a language over JavaScript, right? But there are two more substantive things that people cite for why you don't want to do numeric computing on JavaScript. The first is just sheer community. Now when we talk about JavaScript, the size of the community is huge, but the size of people doing interesting things in numeric computing in JavaScript is small. So if you wanna do something in numeric computing, the amount of tutorials and stuff like that, it's gonna be quite few and it's gonna be kind of a lonely endeavor, right? Another reason that people cite is, well, there's a lack of comparable libraries. There's no NumPy for in JavaScript at the present moment. And this is true, right? Like there isn't a NumPy right now for JavaScript. People are working toward this, but there isn't one. So if you need to do something here and now, well, you're kind of out of luck. But this doesn't mean that you can't use JavaScript or we can't port these libraries to use JavaScript for numeric computing in a web browser. In fact, we need to. And you might be asking yourself, well, we still haven't really answered the question why we should, why would we even want to be able to do numeric computing in JavaScript? Why should we even care? What are the positive reasons for why we need to do this? The first is that you wanna be able to leverage web APIs. You even want access to hardware APIs. You want your application to leverage browser rendering capabilities. You wanna be able to output your data visualization and your analysis as SVG, Canvas, WebGL, as Mike Bostock talked about earlier. You wanna have a tighter coupling between your visualization and your computation. So as we saw on the keynote with the reactive programming style for D3 Express, imagine if you could marry that to a computational backend within a web browser. You could make a pretty powerful proposition there for interactive numeric computing. All on a client's machine. Another thing you wanna take advantage of is ubiquity. The fact that you can run JavaScript pretty much anywhere and everywhere, right? And every single Fortune 500 company now, they're running Node.js in production. Another thing is if any, pretty much any smartphone device has a web browser, so you can run JavaScript there. And now with Electron, you can create desktop applications. So you can pretty much run JavaScript anywhere. And especially if you think about the IoT movement and with Samsung's movement and Jerry script, like increasingly, JavaScript is running IoT devices. So if you wanna develop a numeric computing application and you do it in JavaScript, you have a pretty good chance for having pretty high penetration. Another thing is this distribution. The fact is, is with JavaScript, distributing your computational library or your results or to be able to reproduce your analysis could be as simple as just giving someone a URL, right? There's no special setup installation configuration. All they need is a URL in a browser and then bam, they have your computational program, your algorithms, as well as your data and they can run right there and reproduce it on their own machines. Another reason that you might wanna use JavaScript is this package management. I mean, if you come from other environments, if you're familiar with like PIP and you've done like R packages or you've been familiar with like Julia, you know that package management and other ecosystems is kind of difficult, especially when you think about versioning. And the reality is that for all its warts, like Node.js and MPM of kind of like more or less, in my opinion, solve the package management problem. Like it's an efficient way of thinking about versioning and you wanna be able to take advantage of that for distributing your computational results, version of them, et cetera. And you also wanna be able to take advantage of the largest package ecosystem of any language out there. But there's one other really important reason for why you wanna think about JavaScript for doing American computing and that's the type of applications that you can do. If you went to the decentralized talk earlier this afternoon, you heard the topic of edge computing. The notion of edge computing is the thought of, well, why should, why do we need to do our computational task on a server when a client's machine with its resources and its graphics cards can just as easily do this type of computation? Why can't we outsource some of our infrastructure to client machines so we can decrease our own server cost? You also wanna be able to take advantage of cross-platform applications. Maybe you wanna be able to do something that's a bit more compute-intensive. Maybe you have an application that wants to do like interactive data analysis. For example, let's say you have a mapping application and you wanna be able to do dynamic sampling of your tiles. You need to be able to do some kind of numeric computing for this. Well, let's say you wanna be able to, you have a lot of time series data and you wanna be able to slice and dice and filter and sample, et cetera. You need to be able to do some numeric computing with that. And then maybe you wanna do an application that's integrated machine learning in a web browser context. Let's say you wanna be able to do like clustering or you wanna be able to do object tracking or you wanna be able to do speech recognition, dictation, using hidden Markov models, like all these things. You need to have machine learning. You need to have some kind of primitives, a numeric computing framework within JavaScript to be able to do these kinds of things. Then maybe you wanna be able to do something that's a bit more AI-powered. You want some kind of like smart application. Maybe that does somehow kind of enhance augmented reality or with object tracking within images. And then lastly, you wanna be able to do mad science, right? You wanna be able to do mad science in the web browser. You wanna be able to do crazy things that are really only accessible and available in JavaScript and within the node community, like for example, a peer-to-peer serverless grid computing application over WebRTC, right? That's possible more or less over within using just web technologies right now. And that's really hard to get access to or not immediately accessible in other languages and platforms. So that's great. Hopefully your interest is like, ah, okay, that's kind of interesting. It's a little bit peaked. You're like, I can kind of see some applications and maybe I care a little bit, but I'm still a bit skeptical. And you might be wondering, okay, so like, how do I get started? What do I need to do? And so from there, we need to talk about the state of math in JavaScript, like what's available, right? The state of math in JavaScript is not great. This is our emotional roller coaster, right? It's not great. So we first need to just talk about the standard math library. This is the standard math library in its entirety, right? It's 35 functions. And if you're familiar with like modern computing languages, you know that this is a little bit small. You know, if you're ready to go, it has like 53 functions, this is a space library plus random number generators plus big N, big float. You're like, oh, great. And you come to JavaScript and you go, oh, that's not very good, right? And then if you compare this to, let's say your numeric computing languages like R or Julia, this is like downright tiny, right? What am I gonna do with that? And the reality is this is not much, but there are more problems with the JavaScript standard math library and the ecosystem. The first is, this is kind of the section of the talk where we talk about like here are the warnings, the big red flashing signs you need to be aware of when you start to think about like even creating data visualization packages or whatever else your applications within web browsers. Like here's the things you need to think about. The first is that there are no standard algorithms for the standard math libraries. The specification does not say like how you need to compute something. So each browser vendor can have a different underlying implementation. That's kind of a problem. Another one is that the specification does not mandate a particular precision. Browser vendors are able to make speed and precision trade-offs and they have. And what this means is that you cannot guarantee portability of your numeric computing application right now from like different between different browsers that you could run in Firefox and you could run on Chrome and you can get different results. Okay, and because there's no standard math algorithm or anything else, even from one browser restart to the next, you could have a different underlying math implementation and you could have entirely different results. That makes an issue, especially if you want to do reproducible applications. There's another issue that there's no common code base. This is kind of how the JavaScript community works and how browser vendors each have their own implementations. If you care about really driving this conversation forward, well, it's gonna be kind of a pain because you have to invest a lot of time and research going to different repositories, et cetera. It's not like Julia where there's like one single repository that I can go file an issue for. No, I have to go around to like, I had to look at Rust, I had to look at how the Chrome guys are doing it, et cetera. It's a lot of work. There's also just kind of this slow pace of innovation within JavaScript at the specification level. For example, 64 bit integers have been kind of like on the table, off the table, on the table, on the table for over a decade now. And this more recently, there's finally a specification that's reached like stage two for doing arbitrary precision integers like you would have in Python, but it's a stage two and it may not even succeed. These things take a lot of time because you have to get cross browser consensus. So it's really hard to do things at the specification level to drive math forward on the web. And then finally, there's one more problem, which is that you would think like, JavaScript has been around since like the mid 90s, right? You would think like, hey, and they probably like nail these implementations. I'm sure everything's accurate. No, they're not, right? A lot of the implementations are not accurate. In fact, my version of Chrome running right now does not accurate compute 10 to the 308, okay? And I came across this initial bug because I was doing testing for high precision numeric algorithms and I kept on getting the wrong results or things that defied my expectations. And it's because of this, something very basic. And the reason is because the Chrome team is using a fast algorithm to compute powers, right? They're making that speed and precision trade off. And so there's accuracy issues. And other versions of Chrome, when you compute e to the x, it's not accurate, right? And the reason why this is so important is because these implementations are foundational, right? If you wanna be able to do higher level machine learning and statistical analysis, you need to get the basics right because those errors propagate. And those errors matter when you're trying to decide if someone has cancer or not, right? Like these things are important. And the reason why browser vendors have won in this kind of flexibility is because in the past, they've been more concerned about like games, how to make things really fast on the web. And so they wanted to have like really fast implementations. But the domains to which those concerns apply are definitely not in American computing, right? So we need something else to address these shortcomings. So anytime the standards have let us down in JavaScript, right? We go, the community has always rushed in and created stellar solutions and they've come and saved the day, right? So let's talk about the state of the ecosystem. The reality is the state of the ecosystem ain't great either. And there are a number of issues. 95 to 99% of the math libraries out there that you will see in JavaScript and referring on the web make false assumptions. The first number one assumption they assume is a good standard math library, right? And that's an issue because it just kind of like taints the rest of all their implementations if they wanna do some kind of machine learning or deep learning, right? They just assume, blindly assume that they have a good standard math library and they ignore the reality of what the lay of the land actually is. The next thing is that many people address this low hanging fruit. Like there are just tons of packages out there to compute like the mean variance and standard deviation of an array. And that's great, go ahead and do that. But if you're gonna do like the basics, you better make sure that you do them right, right? And the reality is that there's a lot of poor implementations. One of my litmus tests for any math library out there is like, how do they compute the variance? Because if you take the standard textbook definition where you do like the sum of squared differences, it's not numerically stable. You can have overflow errors or you can have catastrophic cancellation, right? It's my most basic litmus test. 99% of math libraries out there do not do this well. So if you're out there like looking for a package, all right, I'm gonna do some clustering. Do your homework, you need to read the source because most of them haven't really done their homework. Another thing is that there's this kind of insufficient scope, right? So there are some interesting libraries out there that have done like deep learning in the browser. So like Androcarpathia's, CovNet.js where there are people that have thought about like, okay, I'm gonna use WebGL shaders and I'm gonna implement BLAS, I'm gonna call it WebBLAS so that you can do really high efficient computational algorithms on the graphics cards and browsers and that's great. However, there's an insufficient scope here. You can't do, that's not a foundational technology that you can build and erect an entire numeric computing ecosystem for JavaScript around that. And then there's this kind of this lack of ambition, right? So a while back ago, a developer by the name of Mika Lysenko who does a lot of stuff in graphics programming, definitely check him out. He showed that basically the same multi-dimensional data structures that you see in like R and Python and MATLAB, there's no secret to them. You can implement them in JavaScript. And he called it, he created a package called ndarray and he showed how you can do efficient computation in JavaScript very performantly, right? So instead of the community kind of consolidating around this and figuring out like effective ways to leverage this kind of technology, this way of thinking, we're still addressing these low hanging fruit, right? And so this is kind of lack of ambition and really tackling the hard problems. And part of that is just getting momentum into the ecosystem and stir up demand for why numeric computing is important within the browser context. So at this point, you're going this, I'm floored, right? Like I'm on this emotional roller coaster and you really, we're at the bottom. This is not great. I came here to learn about numeric computing in JavaScript. Is anyone doing anything on this? And I can tell you that there are people that have identified these problems are actually working on a solution for this. The project that they're working on is tries to combat a lot of noise within the ecosystem. And that project that they're working on is Standard Lib. Now Standard Lib is a standard library for JavaScript and Node.js with an emphasis on numeric computing. And if you're familiar with the MPM and Node ecosystem, you might be familiar with like modular design. If you went to Emil Bezos' talk, he talked about decomposable functions and separating things out. This project embraces that philosophy to its end, right? It creates many, many different packages for different elements in numeric computing. It includes robust implementations for like special functions or doing floating point manipulation. It does plotting, it does utilities. It also includes a extensive growing list of seedable random number generators that you might find in any kind of numeric computing library. There's also an integrated help and REPL so that you can get REPL docs if you're familiar with like NumPy and you can just do like help and a function. You get back to this help text. Here I'm showing the help for a BLAST implementation because this project has written wrappers for BLAST and LAPAC libraries to do efficient high-performance numeric computing in JavaScript. And with that, there's also web assembly implementations so that you can do this kind of computation within web browsers now. And if you're familiar with the R REPL, I think everyone in here has done R. You know that you can run like example and then whichever function and that gives you, it spins out that example and then you can interact with it. Same thing here, just calling an example with a certain function and you can go back and edit that history and interact with it. So it's a standard library. It's a standard library. It's a piece of foundational technology that focuses on doing high-performance numeric computing, a lot of utilities to build libraries that do like machine learning, statistical analysis, et cetera. Now, unless you think I'm one of those false profits, that's full of a lot of noise and doesn't really know what he's talking about, there's also an integrated bibliographic database with all the primary literature that we use for all the different implementations. And there's also tests against standard reference implementations in Julia, R, and Python. So that's great. You might be thinking, could I'm back on this? We're on the high point of the roller coaster. There's like this library out there that's solved all my problems, fabulous. How can I use it? Roller coaster. The reality is that it's still much in very much an active development. It's been over a year now that I've worked on this full time as an open source developer, living off my savings. And there's still a lot of work to be done. It's very much an alpha status, right? It can be used to interact with it now and it'd be great to get feedback, but there's a lot of work still to be done. And so you might say like, what's needed? What's needed to really kind of drive this forward and how can I start taking advantage of doing machine learning applications in the web browser and within my applications? And what's needed is your help. Your help is needed to do, to write robust and performant algorithms, to write tests and documentation. Your help is needed to make JavaScript a first class computing language and to really bring computing to the web browser. And hopefully, I've shown you that there is a light at the end of the tunnel. I encourage you to look into it, give feedback and hopefully you'll help us get there. So with that, I'd like to thank you for coming to the talk, for coming to the conference. If you're interested in the project, here's a URL and if you wanna help Crowdfund it, there's also a URL. So thank you very much and I can take the questions.