Good morning. Good to see people on time. Appreciate that. As promised, we're going to get started. Doesn't matter who shows up. It's nine o'clock, so we're going to get started. I would like to invite our next keynote speaker, Dave. Dave is the president of jQuery Foundation, and he's also the lead developer on jQuery core project. He's a guy who knows his shit, so let's welcome Dave to come and enlighten us on some of the mistakes that we should not be doing. With not just jQuery, I think he's going to go a lot broader than just jQuery. So over to you, Dave. Thanks for coming. All right. All right. Yeah, I tend to wander around when I speak because I get wrestles up here, so I decided I would get a mic and let me move around and not keep me tethered here. I'm really glad to be here and keynoting for the beginning of day two. I hope you all had a great day one. I did. I saw some really interesting presentations, so some of them actually tied in pretty well to many of the things I'll be talking about today. There's a lot of amazing things you can do with jQuery. It's very powerful, but like many powerful things, you have to be careful because sometimes you can hurt yourself with power, and that's true of things like chainsaws or electric drills or in this case, a gun. And so the analogy that because of course Americans are gun happy, the analogy that we often use is to shoot yourself in the foot. So the idea of a gun is supposed to be to defend yourself, but more often you end up hurting yourself than someone else. So these mistakes are really like shooting yourself in the foot. You want to know enough about how to use jQuery effectively that you don't do that. So you're also going to find out some really interesting, weird tricks about how jQuery works and in the process become a much better jQuery developer and in general, a better JavaScript developer because many of these things are not problems specifically with jQuery. They're issues with the way JavaScript works inside of browser. So jQuery 1.0 was released almost 10 years ago. In January of next year, it'll be 10 years. Now when you think back to what web development was like 10 years ago, it's almost impossible to think back how crude and primitive things were back then. Things have gotten a lot better and things have changed quite a bit. And the best practices that you use for writing websites have changed. So those little animated gifs that you used to use for, I don't remember if you knew, one of my favorites was the hand coming out of the website. I don't know if you remember that one was grabbing at things or the little animated, send me email icon. Those have kind of fallen out of favor or of course everyone's favorite under construction. You don't see those very often anymore. The performance bottlenecks differ a lot from the way they did 10 years ago. JavaScript has gotten much faster. Used to we think of JavaScript as a bottleneck. It's really not a bottleneck anymore. Now the document object model has also gotten faster but we've given it so much more to do. If you think about the features that we've added to HTML and CSS in the past 10 years, we've added these complex HTML5 elements that have their own user interfaces. We've added things like CSS gradients and animations. All of these make the job of the browser even more difficult than it was before, especially when interacting with your JavaScript. So the good news is though that web development is evolving. We're making it easier, hopefully, for people to write web pages with less of the tedious code. That's really what jQuery is about. But unfortunately for most web developers, change often means break. It's very difficult to change the way things work without breaking the way they used to work. I'm not just talking about code. Code and plug-ins are two obvious ones, right? Like a new version of jQuery comes out and your own code needs to change or you have to get an update to a plug-in so it will work. But there are also things like bad programming habits. The reason why web development has changed over 10 years is because there were things that we used to do that we have all come to discover were not really good ideas, things like browser sniffing. So we want to break those bad programming habits. But another more subtle thing is we all learn by Google, right? We go out and we say, I need to solve this problem. How do you solve this problem? I need to find a plug-in for it. I need to find whatever. And so those documented best answers that you see on Stack Overflow or on somebody's blog post, those may not be correct anymore because when we change jQuery or when best practice changes on the web, that 2011 blog post just may not be the best way to do it anymore. But then if you don't change things, how do you stop people from doing the wrong things? If you don't make that change, then how do you stop people from doing the wrong things? It's almost impossible. Now a lot of times people will come back and they say, well, can you just do something inside jQuery to make this work right so that I don't have to go through the pain? And we actually found what we think is a pretty good compromise solution. In jQuery 1.9, we pioneered this by coming up with something called the jQuery migrate plug-in. And what that does is you use the new version of jQuery along with this plug-in, and then you run your web page or your web app, and it identifies through console errors, console messages, what it has seen this code doing that it knows is not really supported by the current version. And it also, in many cases, can make it to the old behavior works correctly. So you can run jQuery migrate with your own code. You look at the list of warnings it's giving you, and you can go back and fix your code or go find the plug-in update that will solve your problem, or maybe even switch plug-ins. But you can also use jQuery migrate for a long period of time. I don't recommend that. And that's why when I say fixing the rest is up to you, it really is worth reading the error messages and the warnings that you get and fixing the code rather than just saying, well, I'll just always use jQuery migrate. Really, migrate is intended to be a crutch and not intended to be a long-term solution to your problem. So there are some changes coming in jQuery 3.0. We talked a little bit about these yesterday. Deferreds are going to be promise A compatible if you're familiar with the promise A spec. The most important thing from a practical sense is that that changes the behavior of errors. Today in jQuery, if you use Ajax and an error occurs, it throws a message on the console. If you're using promise A promises, you won't see any error whatsoever. And it's very important to use catch on a promise chain to make sure that you handle any error even if you don't think an error will occur because that's when they always occur, is when you don't think they will. And there's also a big change coming that we hope we can make stick regarding show and hide. And I'm going to be talking about that in detail a little later. But let's talk about some other foot gun problems that people have had with jQuery in the recent past. One is jQuery latest.js. Early on in jQuery's evolution, someone said, you know, it would be really handy to have a place where I could go and get the most recent version of jQuery so I could download it to my own site and use it there. And so John Resick said, this is great. Every time we release a new version, we'll just copy it to this jQuery latest.js file. And we'll even have a minified file. That'll make it really easy so that you can just make your own copy of that file. Well, unfortunately, what some people did is they said, hey, this is wonderful. I can use the script tag to always run the latest version of my site. Now, when you think about what that does, every time we release a new version of jQuery, it will change the version of jQuery that runs on your site. That is a version that you probably have not tested with. You have no idea whether it works with your site. But because you have directly linked to jQuery latest, you have now possibly broken your site for everyone who comes and visits your site. Now, that would be a limited problem, except think about all the websites that are created in the world and really never maintained. So these sites get created by somebody with the best of intentions and it's like the Space Jam site, which was built in 1996 and it's still there and it still works. And that's really what we all aspire to do. We want to build something that lasts forever, not something that lasts until the next jQuery update. So what happened is we started getting error reports from people and people were saying, I got the latest jQuery and it destroyed my site. What's wrong with your people? So we said, well, this is going to be a problem in this case. Someone actually noticed and hopefully they changed their site. But in the general case, we can't do that. I mean, we can't go and change someone else's site. So we got together with the Google people because they saw the same problem happening with people who were using the Google CDN with a non-specific slash one. And we agreed that we were going to freeze the jQuery version at version 1.11.1. That version will never change anymore because what we were finding is as time progressed, we were breaking sites and this essentially says latest is now always going to be the same version. And the reason we had to do this is because there were too many people in the wild using jQuery in a way that broke their own sites and we had to protect them from themselves. So my message here is really never use jQuery latest anymore because it doesn't mean what you think it means. So always include a specific version of jQuery. Always test your site with that version and only upgrade jQuery or your plugins for that matter when you have the time to retest. So I have no problem with your website that you built two years ago using jQuery 1.9 because that's when it was built. If you're starting a new site, I advise you use the latest version of jQuery. But don't feel like you have to just always go and upgrade jQuery because when you do that, you always should retest to make sure that all of the plugins that you're using work with the latest version. So we talked a little bit about jQuery 1.9 and even though it's been a couple of years now, many people are using older versions than jQuery 1.9. And two of the things we removed there were dollar dot browser, which was using browser sniffing. And this was an example of something where we said, this is an extremely bad practice. We had marked it as deprecated since jQuery 1.3, which I think was 2008. But we kept putting off removing it because people would always give us some obscure reason why it was important. But we finally did the right thing and jQuery 1.9 took it away. There was also live and live was overused. And in particular, one of the reasons why we removed it is because you have to be very careful on Apple touch events that things don't always bubble the document. And so when you're trying to build something, you may test it on a desktop machine and it works fine. And then you get to testing it on an iPhone and it doesn't work. So we wanted people to think specifically about whether they wanted to use something that bubbled to the top of the document. There's also a performance issue there, where anytime you let something bubble all the way to the top of the document, it is slower than if you could handle it closer to the point where the event occurs. And again, the jQuery migrate plugin is going to be able to help you with a lot of these problems. Because anything that we took out of 1.9, just I believe everything that we took out of 1.9 is handled by the jQuery migrate plugin and will help you find any problem if you're out there trying to upgrade an old site that's using jQuery 1.6. Now, there's certain things that jQuery does for you.  It's not just a single barrel foot gun. You can shoot both of your own feet and two of your friend's feet, I suppose. It's amazing what the browser has to do. In 16 milliseconds, this process occurs. When you make a change in JavaScript and it affects the HTML or the DOM, the browser has to create a new render tree. It lays out that render tree the way it's going to look on your infinitely scrolling page, and then it paints it onto the screen. And all of that has to happen every 16 milliseconds, ideally, to get a very smooth flowing animation. If you do something that takes a lot of work, either by the browser or if you do something in your JavaScript that takes a lot of work, you'll create something called jank. It just makes the browser stutter. And you've probably seen that either in jumpy animations. You might see it when you try to scroll a page and it just seems to get stuck for a second. All of those are signs of jank, and they're signs that you're trying to make the browser do more in that 16 millisecond frame that can really be done. So there are a couple of selectors and methods that in particular can cause some problems with that 16 millisecond window. Two of them are visible and hidden selectors. So if you're familiar with them, they are custom selectors that you would use them just like you would any CSS selector, but they're special. It essentially says, find me an element that is not only whatever else I ask for, but it has to be visible in the document right now, which means it's not display none or a width of zero or a height of zero. And the converse of that is hidden. So to answer the question if something is hidden or visible, we have to go back and ask the browser, because the browser is going to process every 16 milliseconds and it will be able to tell us when it figures out the layout, whether this element is visible or not. Now that could be a problem, because let's look at a simple example. Let's say in a high frequency, like a mouse move handler or a high frequency timeout, we're doing something like this. Maybe we don't do it every time, but in some case we add a class, we remove a class from the body, and it should say add class there. And then we look for visible selectors, visible paragraphs, and we're going to color them blue. This isn't exactly the code that I came across, but it's similar to it. So it's a very simple thing. We're just changing the class on the body, and we're going to mark some elements blue. But we're going to mark them blue if they're visible. So I'm going to add something called console time. It's a really interesting API that you can use the browser tools with their timeline feature and actually see the amount of time it took to run a series of code that's in your own application. So here's what it looks like. This is in Chrome. Those two lines of code took 30 milliseconds, which is a pretty long amount of time. If you recall, I said it, 16 milliseconds is ideally what we want to never exceed if we want to keep our page from being janky. And when you think about the extra amount of overhead there is in the browser trying to do something as well. We are past two frames worth of effort here for the browser just to tell us whether some paragraphs are visible. And the reason why that's true is you can see this recalculated style takes a huge, huge amount of time. And the reason it takes a huge amount of time is because we had to add a class to the body. Well, all the paragraphs are under the body. And that means that the style we added to the body potentially may have changed the visibility of those elements. And in fact, one of the nice features you get out of Chrome is this yellow triangle. When you see that on a Chrome timeline, it's telling you that some piece of code below this has forced layout. Now this is where jQuery gets blamed for a lot of the sins of the world. You can see that jQuery is named at the scene of the crime here. But what really happened is we called add class, or you called add class, so jQuery added a class, and then later an event happened that forced an event, that same event, forced layout by asking for the width of an element. The reason why it asks for the width of an element was because that's the way visible is implemented. It says, is the width of this element zero? Okay, well then it's visible. So something as simple as those two lines caused us to lose two whole frames. So let's use a class instead. Instead of using the visible selector, I'm going to use a class called showing. In the case where I saw this on a client site, we could add, they were actually tracking these things themselves, and we could easily add a class called showing that would show, say these paragraphs needed to be showing. Well wow, look at that. Instead of 30 milliseconds, now we're at eight milliseconds, only half a frame. So we've increased our performance significantly, we've gotten rid of the jank problem, and all just by making a very, very small change to the code. So this is where I'm, we're knowing the way the browser works, and what it does is very important to getting the best performance out of the browser. So I always, I always have a problem of trying to explain to people, depending on how well you understood what I just went through. Some people will come away with the idea that visible and hidden are just horrible selectors and they shouldn't be used. There are times when they can be applied to good effect, but what I found is a lot of times people don't know when those best times are, or they never come back to profile the code to see what the effect is. So sometimes the easiest thing to do is just to avoid them all together. But in particular, for this case, don't use classes on elements for things that aren't presentational information. Sometimes people will use classes as kind of global variables for their JavaScript. And that's not a good idea, because when you do that, you can sometimes make the browser think that it does need to do a new layout, because you've added a flag to the body that really nothing changes presentationally because you added that class. It's just a flag to some other piece of code to tell it that you've done something already. So don't use classes for JavaScript-related state. You can either keep that in JavaScript only, or if it's something that does need to be kept on the document itself, use data attributes or jQuery's data method instead to store that data, rather than class names, which really should be as much as possible saved from presentational data. And that will eliminate the problems that you might have with forced layouts. Now somewhat related to that, you show it hide. And I mentioned in jQuery 3.0 we're looking at making a change here. So it seems like it should be really easy. Show makes an element visible, and hide makes an element invisible. And then today we change the element style attribute directly on the element to make sure that it sticks. So we don't use a style sheet or anything like that. I guess if we were really picky we should try to set the important attribute to make sure it sticks. So what possibly could be wrong with that? It seems like such a straightforward API. Well, here's a few examples. Not all of them, but just a few of them. What about detached elements? What does it mean to create an element outside a document, to show it, and then append it to the body? Since the element doesn't have a hidden attribute on it or a display none, do we need to do anything here? Or can we just append it to the body? Well, obviously if it was initially hidden, then we would have to do something. We would need to set display inline, right? We would have to make sure it's showing. But what if the parent is hidden? Well, we can't do anything about that. We can force that element to be display inline, but we can't change it to be visible because the parent's hidden. But what if the display of a span is not inline? What if it's blocked and we append it to the document? Well, if we set it to inline, we've broken the page. What about responsive pages? If I have a style sheet that changes the display of an element based on the orientation the page is in, then if I use show, I forced it to a specific display orientation and whatever I did with my media query doesn't apply anymore. And that's actually not all that uncommon, especially like in menus and such, maybe use display inline for one orientation and display block with them stacked under each other for a different orientation. So all of these things kind of interact to make show and hide much more nuanced than you might expect them to be. And people will sometimes will say to us, well, why should you change working code? I mean, yeah, show and hide are kind of weird, but why would you want to change them? Well, some of the cases that we looked at there are still broken today because we can't really reliably determine whether an element is blocked or inline or what's going, we don't know when you create an element outside the document in particular, what the document's going to look like when it goes there. So that's a problem. The most serious problem as far as best practice is concerned is our currently working code forces layout. So to determine what the current display type is, we actually have to do some kind of crazy things to the document to say, well, if we were to put a span in this document right now, what would the current display type be on that span? And that way we can try to set it to the right version when you show it again later. That's a serious problem, especially on large pages, because when you're dealing with thousands of DOM elements and you're going to show 10 or 20 of them and we're having to go in and jigger the page forcing layout, that can cause various, very serious performance issues. We saw one that Paul Irish from the Chrome team pointed us to, it was in Wikipedia, and this page had a lot of other problems. It wasn't just a jQuery show and hide problem, but their editor took 13 seconds just to initialize when you load the page. So, you know, our goal is to try to make sure that when you use an API in a way that seems somewhat reasonable, then you get results that are somewhat reasonable, and right now show and hide don't seem to really fall into that category because people don't expect some of these crazy things to occur because they're not looking at the boundary conditions. The solutions to this, as I mentioned, we're looking at some possible solutions in jQuery 3.0. A lot of those will involve changes that break existing code. I think the best way to handle this, from your perspective, when you look at how you're going to design jQuery code today, try to use classes to show or hide elements. Don't use show and hide. Just have it put a class on the element, and that class can have display none, or maybe it's got a media query that goes with it so that it changes display properties based on the size of the screen. This allows us to avoid edge cases with forced display types, non-default display types, and lets us avoid the stuck, the forced layout problem, and that way elements also aren't stuck in some state if you are using media queries. That makes it work with responsive design. So I thought this was a very cute tattoo, a gun on a foot, another take on foot gun. See, this is what's great when you start doing image shows, you just find everything. This is an Ajax foot gun. Okay, what does it look like this code does? It looks as bad as straightforward as you could expect. I'm going to get file.txt from the server, and when it comes back, I'm going to alert out the data that I got from the server. Okay, nothing could possibly go wrong. In fact, that's why I didn't bother putting an error handler in here, because clearly there's no reason for an error handler. So disregard what I said about needing to check for errors before. Well, a lot of things can go wrong. Imagine if I, there's a method called Ajax setup, which lets me change the default parameters for Ajax requests. So some very cruel person has said, well, the type is going to be post, and the data type is going to be JSON, and the timeout is 500 milliseconds. So when you do that, the chances are that your server, this will fail in so many ways that you'll never get this request to succeed. First of all, when you send the data, you're going to do a post request now, rather than a get request, which is probably not what you meant to do at all. Also, when the data, if it were to come back, the data type is JSON. So unless that file.txt has JSON, when it tries, when jQuery tries to parse it, it's going to throw an error. But let's assume the file had JSON in it. The timeout is 500 milliseconds, unless the server is very close to you, it's probably going to take more than half a second to reply. And when, so in any of these cases, you're going to get some kind of error. And you could literally spend your life trying to figure out what went wrong. Now imagine if you're writing a big application, and you've got one group over here that is, you know, that is responsible for one thing on the server, and they're making AJAX requests, and they go, well, these are the defaults we want. Obviously, we always are posting, and we want to get JSON back, and we need a really short timeout, because if it doesn't happen quickly, we just want to give up. You, on the other hand, are on the other side of the building, and your job is to just make normal requests, and you're looking at the documentation for jQuery and going, well, the default is a get, and the data type is intelligent gas, which on a text file would probably be text, and the timeout, there is no timeout, it waits forever, which is exactly what you want in your case.  Global settings really are a big mistake that we made, because it's impossible to tell at the point where the AJAX call is made, what the code really does. They contradict the documentation. So really, you know, if we wanted to make our AJAX documentation even longer, every place that we talk about a parameter, we would go data type. The default is this, unless you set it in global AJAX settings, in which case all bets are off. You know, every one of these parameters could be set in global settings, and essentially change the way jQuery works. It makes it very difficult for plug in writers, because the plug in writer, as a defensive measure, has to specify every setting they think could possibly be changed in an AJAX request. Otherwise, their code could break. So I would definitely advise don't use AJAX setup. Now, you're probably thinking, but I want to call AJAX from 100 places in my code. That may be a code smell right there, but if you say, well, I want to call it from many places in my code, and I need to have the same set of parameters that I want to have to type them in every time. Well, obviously, there's ways around that, right? You can just have your own command, like in this case, you can set the default parameters, and then just have your own function that you call, rather than calling AJAX directly. I think that from a semantic standpoint, like I called this with a remote command, because I'm thinking that it's probably making kind of a remote procedure call, that's a better way to do it than calling AJAX the raw way anyway, because you're kind of defining logically what you want to do rather than just making a direct jQuery call. So, jQuery, I think that as far as the API confusion goes, the dollar sign constructor, well, AJAX probably comes in first, but dollar sign comes in second. This constructor takes everything. And let's see how many of these you know yourself. Okay, so this, that's document ready, right? You put a function in the dollar sign, and that means when the document is ready, execute this function. This wrap, say, a DOM element, so that's, you probably use dollar sign this all the time, right? And in most cases, in like event handlers, dollar this would be wrapping the element that the event occurred on. You can pass an array of document elements, of DOM elements, and then that becomes the collection. You can pass a jQuery, you can pass a plain JavaScript object. This is kind of an obscure and not super well supported signature. You can pass a single element, like in brackets div, and then you can set a list of attributes. Again, this is kind of an obscure one that I don't particularly like, but it's there. You can have a selector string, and you can have HTML. Any of those, basically you can pretty much throw anything at dollar sign, and it'll give you something back. It won't always make sense, because I mean there's also ones like null and undefined, or empty string, and those, those create an empty set, or just nothing, you know, dollar per end per end is an empty set. So it takes a lot of things, and it takes a lot of non-things. That makes it a somewhat dangerous method. You have to be careful about what you pass to it. That's particularly true when the code might be trying to entice you into making an interpretation that's wrong. So in here you might say, oh well obviously somebody's selecting an element out of the current document, and appending it back to the bottom of the body. But then selector is just a variable name. Selector could be any of the cases that we looked at before. It could be a function, or maybe it is a select, maybe it is a string, it's a selector, but what if it's actually HTML? Well that would be bad, right, because it doesn't have to be a script that alerts 42. It could be a script that steals cookies or destroys the page, or whatever it's doing, likes somebody on Facebook. I mean those are the typical exploits that you'll hear about is the ones where somebody will inject something into a page, and it makes you like them on LinkedIn. JQuery APIs insert HTML. That's what they do. That's what they're supposed to do. So sorry about it being a little dark there, but use JQuery to manipulate HTML. It's not a bug that JQuery can manipulate HTML. But it can be a significant foot to have done if you're not careful. HTML can have scripts. The scripts will execute when you inject them. If you're doing things where you want to change something on the page, and it only has text, then use .text, not .html. I think a lot of times people use .html as kind of their go-to method for changing anything on the page. But you have to remember where you got the content from. So don't blindly trust any data that you got from the user, from the URL. You have to even be careful about round-tripping data to the server, because you can imagine situations, for example, where the user fills in a form, submits the form to the server, the server returns that data to you on the page at times, and that page, that data they typed in could have HTML, or the data that some other user saved into the database could have HTML. So this is a, it's a significant problem that's much bigger than JQuery, but it's something that you need to remember when you're dealing with JQuery, that when you manipulate HTML, you have to be very careful about where you got that content from. Another classic one, which we actually closed in JQuery, we closed this in JQuery 1.7, but document.search is the part of the URL from the hash over. So if you use the hash, that conveniently is also an ID in a selector. So people will use this kind of shortcut and say document.search, add, and then they'll do something with it, like add class selected would highlight whatever ID, whatever hash they put on the URL that they just went to. But there's no guarantee document.search is just a selector. It could have HTML because it was on the URL, and you don't know where the URL has been. It might have been, it might have been modified by an attacker. It might have been a link that the attacker got a user to follow and then injected script. So if you're not careful with the way you use JQuery, if you're not careful with the way really you design your site in general, you can get yourself into some really big problems with cross-site scripting. Okay, so let's go to some things that are a little less catastrophic, but still something that will make your code better if you follow some of these rules. A lot of times when people start using JQuery, they always want to do every line of JavaScript of JQuery away. And that was never really the intended use of JQuery. When you think about when JQuery was created by John Resig ten years ago, every programmer at the time used plain old JavaScript with sometimes with some libraries added. And they were very familiar with JavaScript. They were very familiar with the document object model. And because of that, they were very comfortable with using DOM elements directly. And in fact, you see the results of that when like an event handler that this value is a document element. It's not a JQuery object. It's a document element. Now, John could have said, well, you know, let's just make that a JQuery object. But it actually was more efficient and more comfortable, especially for developers at the time, to make that a DOM element. So here we see a case where we want to toggle all the checkboxes in a collection. And doing that, we go through and we change the property and the checked property. Well, you could certainly do it this way. You can see it's kind of, well, it just is ugly in a lot of different ways.  And there's just a lot of duplication in there. You can do it just as easily this way. Just use the check property directly on the checkbox. That works everywhere. And you can see it's a lot prettier. You're still using JQuery, but you just don't need to use it to access. And it turns out there's a lot of cases like this. So there's the check property. Actually, this is checked. It is even more of an abuse. I guess people like it because it reads more like English. But this, these cases run roughly 100 to 200 lines of JavaScript code to do what they do. And this, of course, these are all one line. So it's about a 200 to one ratio. Now, in most cases, none of those are time critical, right? When you're toggling a checkbox, whether you run one line of code or 100 or 200, usually it doesn't matter. It won't make your site that much slower. But why run 200 lines of code when you can run one? And you can see it's, it just looks better. It's shorter to type. And there's, in the same way, there's a lot of custom selectors that jQuery has that we've added. We've mentioned a couple like visible and hidden. They extend the standard CSS selectors, but they're not supported by query selector all. Now, what that means is that we actually have to use our sizzle JavaScript engine to parse and execute that selector. And that makes things a little small, a little slower. But in general, speed is not the main concern there. In the visible and hidden case that we looked at, the fact that we're going through sizzle is not what makes this slow. What's making it slow is the fact that we have to ask the browser a hard question, and we have to go through the little jeopardy music while the browser figures out the answer. So we want to try to avoid, whenever we can, these old custom selectors that don't really add that much value. And the ones I'm talking about here are ones like colon checkbox. Yes, input type equal checkbox is a little longer, but query selector all knows about it. The same with colon button, which I always forget when I've seen people use colon button. I always forget that it includes not only button elements, but input type equal button. So it's a little bit confusing sometimes that you actually have to look up or memorize the definition of these to know what each one of these does. First and last in particular, those sometimes don't do what you think they do when you're dealing with multiple, the children of multiple elements. So first child and first are better options in many cases and more obvious what you're doing. Now, I do want to point out there are cases where it's not a good idea to use native methods. So you've probably seen the you may not need jQuery crowd talking about how you never need jQuery. This is actually a couple of examples of where you can get into a lot of trouble if you think that you can just use native methods for everything.  Here's a few places where you have to think about the level of browser you want to support. This first example here does not work. There is no class name. There is no class name object on a DOM element in IE 8 or Android two point anything or for that matter on. I'm blanking what's what's the headless browser of phantom. Yes, I meant class list. Sorry. I meant class name at the bottom. I meant class list above. But class there is no class list on IE 8 Android or phantom and a lot of people use phantom for their testing. I really hope 2.0 phantom comes along sometimes soon. But right now, if you have some headless tests that you do, they'll break if you start using class list instead of add class which will work everywhere even on all of those browsers. Now, there may be other solutions that you can use. For example, if you can assert that it's okay to just set the class name and you can just set the class name and that's the simplest way to do it. It's probably the fastest way to do it as well. But it's something that you need to think about as you start talking about well, how can I get you know how can I reduce the amount of jQuery that I use. Think hard about that especially, I don't know, are Android 2.3 phones being sold widely here in India still? They are. Okay. So, you know, if you want to support those phones, you need to make sure that whatever solution you come up with still supports those browsers that don't yet include class list support. So I've gone over a few cases here where modern jQuery has changed the way it's worked, but it can be safe and effective when used as directed. Don't assume when you go out on the internet and start looking for solutions to your jQuery problems that the answers that you find, especially ones that are more than a year or two old, don't assume those answers are correct because even if they still work, especially if they still work but only if you include jQuery Migrate, don't assume that those are the best solutions still. Unfortunately, people just don't go back and update their eight-year-old blog posts. I don't know what. Instead, use tools like jQuery Migrate if, you know, if you're having problems or especially if you're trying to upgrade an existing site with an old version of jQuery. That will help you find those bad practices and fix them. And please don't just use jQuery Migrate as a way to prop your problematic code up forever. Migrate does a really good job of giving you error messages and we want people to continue to upgrade jQuery because each one of the versions that we put out improves performance. So every time you put in jQuery Migrate with an old version or even with the latest version, you're kind of destroying the work we've done. You're making jQuery slow again, which will probably affect your perception of whether jQuery is a good platform for you or not. So, you know, as much as you can, keep using the latest and greatest, we'll try to keep making it greater as we go on. So, I think we've got a little bit of time left if you want to ask some questions. I know there's some questions out there. Everybody comes up to me in the hallway and asks me questions. Here's your opportunity to have your question answered so that everyone can benefit. Yeah. Yeah, .live. It said, the question was, I mentioned .live and you wanted a little more elaboration on what I meant by that. .live has, well, actually if you go look at the manual entry, the jQuery documentation API entry for live, there's a big list of problems that live has. Just off the top of my head, some events don't bubble. They can't be used with live. Apple touch events don't bubble to document, so they can't be used with live. The selectors, the bubbling process is very expensive because if you're 10 levels deep, then we have to test the selector you gave against each one of those 10 elements on its way to the document to see if any of them meet the criteria. The list goes on and on, though. So, there are performance issues or reliability issues and that's really why we got rid of .live. You're seeing less and less code that uses .live. Usually, it's, again, old Stack Overflow answers, old plug-ins, and hopefully we can, over time, get rid of more of those and not have to be dealing with, you know, with you trying to figure out, is it safe to use this plug-in? Oh, no, it uses .live. Another question? Somebody had their hand up here. If you stretch, I'm going to assume you're asking a question. Yes. So, you mentioned that dollar.ajax setup is not a good practice to use. So, why do we still have that supported in our API? Why is Ajax setup still in there? Mainly because a lot of code still depends on it. So, it's kind of the same reason why it took so long to get rid of some of the other bad things. People will say, I have no better way to do this or, you know, as, I mean, if we could put out a version of jQuery that represented everything we wanted to do, it would be wonderful. The problem would be, I think no one would end up using it. You know, so Ajax setup is a good example where I would strongly advise nobody uses it, but we have the problem of trying, and also I want to make people aware of it so that when they write plug-ins, that they know they have to defensively program against it. But trying to remove it is much more difficult just because so many people currently depend on it to make their code work. So, we would be requiring that they actually go and, you know, rewrite a lot of their code. Hi, David. Yeah. Oh, okay. We are using extensively .on events, .on functions for the events. So, are there any best practices to use .on events to make our performance faster? I'm sorry, I didn't quite understand the question. So, there are two ways to bind the events. First, directly, you can bind events, .click, and all the things, and you can use dynamically using on. So, is there any bottleneck? Well, the form where you use a selector with it is somewhat similar to live, right? It just uses event delegation. Is that what you mean? Event delegation versus directly binding to a particular element? So, when you bind, event delegation is a really powerful technique. I think that, in particular now that everybody is in the MVC, that one good reason for avoiding live is that you probably want to make the container for your event delegation be the container for your view, and you don't want it to go outside that view. So, I think it's a fine thing to do if you want to make it, for example, so that all of the events in a view are bound to the view container, and then everything inside is just delegated to the container. Or you can bind them directly to the elements. Obviously, if you're, for example, you've got a table with 100 elements in it, it's much, much better to put the element on the table element or on the table body than to put it on each individual, you know, each individual row of the table. Yeah, one more question. Are there any best practice regarding even namespaces? We use even namespaces a lot in our application. So, are there any CVS or fall, I mean, drawbacks with it? Well, even asking about event namespaces means that you are a pretty good event, a best practice person already, because unfortunately, a lot of people don't use event namespaces. Especially in a large page, you can end up removing someone else's events. So, best practices on event namespaces, the main thing is just to choose names that are somewhat unique and to use them in your own code whenever possible. I think especially when you're talking about a plug-in, make sure that your plugins are using namespaces so that, again, it's a defensive maneuver to make sure that your plugins don't have their events removed by some other piece of code. So, I mean, you could use a small number of, you know, custom things like underscores if you want them to be really unique. I think the main thing is just to make them long enough and named probably like if it's a plug-in, put a prefix of the name of the plug-in. Hi, Dave. Over here. So, I wanted to ask you whether jQuery is going to support mobile events in the future like touch, drag, touch start. So, normally we have to use other plugins to rely on it or fast click. Well, fast click is a problem that was created by Safari, right? The ideal for us is that people would go to pointer events and then you wouldn't really have to worry about some of that kind of thing happening. Some of the other things about gestures, they're more high level. So, it's probably better to have them occur in a plug-in. The plug-in can generate an event you could listen to with jQuery. But if it requires measuring things, for example, knowing how far a swipe is or those kinds of things, it's probably better to put that out in a library because a lot of times you'll want to tweak that and maybe platform-specific. Ideally, in jQuery Core, we would like the events and things we handle to be a pretty cross-browser and do anything that's higher level elsewhere. So, when it comes to jQuery UI or the tep pointer event plug-in, we can put pieces together to build a full application. But we don't want to think that it has to all be inside jQuery Core to make it work.  And when you look at the documentation, it's fairly nicely called out that this is not a good practice. It has performance issues and things like that.  And if it works, they just use it. They don't kind of really think about the performance issue with it. So have you guys considered kind of putting a log debug message when someone uses something that's considered bad with the same warning that you have there? So if someone happens to use, they could see the warning as a debug message but not hurt performance in production. jQuery Migrate does some of that. The challenge there is that it adds a lot to the size of the file. And again, people can know nothing about jQuery or jQuery performance, but they can look at the size of the file. And we always get dinged for that. So I actually talked with Paul Irish on the Chrome team. And he, when he was debugging some of the performance issues he was looking at, we were trying to figure out ways that we could have Chrome tools actually try to identify some of these problems and propose solutions and say, you know, don't do this. That's also why we want to be able, for example, if we solve the problem in jQuery 3.0 of forcing layouts on show and hide, then when we saw it being used, we could say, oh, if you upgrade to jQuery 3.0, this problem will be solved for you. Right now we can't do that. So yeah, it's always difficult because sometimes, I guess we could detect the problem universally and then just have a little cryptic message and say, you're doing it wrong. Go see the documentation. But if we had a specific enough message, people always want messages that are very specific. And I understand why. So they'll say, why is it that I can pass on a data type that's not a valid name? It's like, well, because it could be a valid name, you know. And what they want is a message that says, warning, you have passed in something that isn't a valid name. And if we did that, we would have hundreds of error messages in the code and the code would be a lot bigger. Hi, Dave. Why do we have $.get in the API? We already have $.ajx where we can set the type to get. We do have get. We have get, post. Yeah, like why do we have a separate API? Oh, wow. Yeah, that is a good question. There was a point in JQuery's evolution where I think people were thinking along the lines of, what are the fewest number of characters that we can implement anything with? I am not a fan of get, post. You know, a lot of these that are kind of shorthand methods for a shorthand method because it does make it, I mean, they're implemented exactly that way. And $.get is just a little wrap around Ajax. Yeah, I mean, it doesn't even have the error thing. If suppose it does not go to success, it does not have an error block as well. Yeah, I completely agree with you there that a lot of those are not essential for the boiled down API. All you really need is Ajax. You don't need load, get, post because they can be built pretty simply off of the existing Ajax API. It's usually, those come down to, now that we've put them in years ago, trying to figure out whose code we break in the process of trying to remove it. And if you actually look at the implementation, it's that much. So there's almost more work in removing them than in leaving them in. Certainly today, as we look at what features we decide to add, we look really hard at those things because, yes, it's only this much code, but then it's several more pages of documentation and unit tests and team time and all of these other things that are involved that sometimes don't, when people talk about it's only this much code, when adding a new feature, they don't realize what the back end costs are. So you have a good point there and really if we had that time machine that we all would like, we probably wouldn't have it. Hi Dave. A few minutes ago you said that applying class at a body tag level is not a good practice. Is that only because it is at a higher level and it causes the whole page to get repainted? I'm sorry, which is not a good practice? Applying classes at a body tag level. Applying classes, if you don't need to apply a class to the body to change something about the layout of the body, it is better not to do that because it's not always but sometimes possible that the browser will think that the body class changing will mean that a layout needs to be done on the entire document. So a practice that I've seen done quite a bit in the past is someone applies a class to the body as a programming flag. I am done with doing this. I am in the process of showing a dialogue or whatever but it doesn't actually change anything about the display of the page. It's simply a flag that they use of has class later to see if the class is on the body that tells them the dialogue's being displayed. Instead of using classes for that, it's much better to either use JavaScript variables or data attributes because those will definitely not force a layout. True, I got the point, but my point is is it only because it is a higher level or is it okay to add such attributes, add class attributes at a lower level, such as a span or a small, at a lower level, devs, et cetera. But that also cause problems. It can cause problems. Anytime you add a class and if it potentially affects the presentation of the page and then only a few levels lines down somewhere in the same turn of the event thread, you go and try to access something having to do with the part of the page you changed. The browser will need to stop working on your code and go recalculate everything and give you the answer. So you want to try to avoid that case which is called force layout. Thanks, David. Hi. Sure. Yes. So what I understand from one of the previous sessions is that we could use Sizzle, the selector engine of jQuery, independently of jQuery. So could you give me some examples of projects for which Sizzle would be the right fit but jQuery would be an overkill? Probably the most common situation would be where if you decided in a project that you're not using jQuery but you want full selector support on really old browsers. I don't see that as being a really common need though because usually those places where you're not using jQuery you might be using like Angular or something. They already exclude those browsers to begin with. So they're probably today on that many places where you would need to do that. If you decided you were going to extend the selector syntax yourself, Sizzle provides a way to do that. And so if you were doing something a little out of the ordinary and you wanted to make your own custom selectors but again, not use jQuery, you could do that for Sizzle. Thank you. Are we good on time here? I think we're, okay, sure. So when you're doing large HTML manipulation, so it's not like one level deep probably, I've got a div and maybe a paragraphs or another spans inside it. So say two, three level deep hierarchy. Then obviously the, and if you have a dynamic data in that then manipulating that as a text or a string is messy. So instead of that, the jQuery plan to have a kind of, I mean, very lightweight version of templates just like how underscore does, is it on the plan? Yeah, I don't think we need them because there's so many ways to do templating now. You can use mustache, you can use, you can use, depending on what kind of templating you want to do, you can use ES6 translation with ES6 templates, you can use, if you're expecting to go to like DOM templates, you can use that syntax. So there's so many ways to do templates that I don't think we would want to create a competing one. Especially if it wouldn't make sense to try to do that in core itself if it increased the size of the core library. Cause I think the majority of people would use one of the existing solutions out there rather than ours. Okay, great, thank you very much. All right, did you guys enjoy the keynote? That shows by the number of questions, right? Typically that's how we measure how good the talk was. So thank you, Dave, that was very good. I at least learned a few things that I was doing in jQuery that was wrong. So that's always good.


Hello, welcome to this CUBE conversation. I'm John Furrier, host of theCUBE here in Palo Alto, California. We're bringing you a special conversation with a venture capitalist, good friend of theCUBE. We're trying to figure out which year he first was on theCUBE, but he's an OG, original gangster of theCUBE community, Alan Cohen, general partner in DC, VC, many careers in running early stage companies, wireless to networks, Nacira, Airspace. Really here to unpack the future of how AI will be impacting the technology industry mainly around kind of the conversation that grew out of the Juniper HPE acquisition that HPE bought Juniper for $42 billion. Really around the crown jewel of missed AI, which Alan has some DNA. He knows some of the folks, there was an advisor. Alan, great to see you. Thanks for coming on theCUBE and chatting with me. It was great to be here, John. I feel like a hobbit at, you know, I'm revisiting Brie after the, or after the World of Wars. Yeah. Well, it's been great. You and I have been friends for over a decade now. theCUBE's on its 13 year or we're going through another inflection point. Again, what's super exciting is again, I always say in theCUBE, I wish I was 25 again, because this next wave inflection point is real. The AI hype is matching what is coming in terms of substance. So it's pretty close to hype cycle meets, you know, meet on the bone. It's going to look like the web, I think, but we can debate that. But this next wave is coming fast and it's AI is the buzzword, but it's really a lot of things going on with AI. And specifically, everyone talks about consumer, chat, GPT, whatnot, but it's a lot of other areas are going to be disrupted. And they're new things. So some of them are, you can pattern match a little bit. Oh, it's like the web, it's embryonic, it's going to grow and get faster. But the bet's going to be on how the infrastructure and apps kind of start rolling together. Who does what? What is going to be automated away? How human can be part of that loop?  So what's your take on the AI wave right now? And just generally zooming out before we get into the MIST and or AI ops or impact to technology? Well, by the way, John, I saw your show last week with Steve and Zia and Jake and you guys unpacking. MIST, I was actually, as you mentioned, I was a board advisor at MIST five years ago when they got started. And that was kind of the first glimpse of using machine learning algorithms to actually replace human beings for the management of IT networks. But it's funny to see that the technology industry is actually catching up to the real world. So for the last five years, I've been investing in companies that use AI, computer vision, machine learning to run businesses we don't think about in the tech industry, rockets, robots, microbes, physical security. And they have been incorporating the ability to consume massive data sets for decision making. And anywhere we have, as my partner Matt Ock always likes to say, we do security as a service as. We have a company for them that is a drone detection company evolved where I was the chairman and we took them public. Those are companies that use computer vision and machine learning to actually protect people. And they've been doing that for seven or eight years. So to me, what's happening now in the tech industry is an industry that had been built clearly on writing software but not necessarily using generative AI, massive data sets to actually instruct their actions. They were really configured and managed by people. So that to me is like the wave that we're starting to see. And your point is that the app is at the infrastructure. Well, the generative AI is going to be the decision maker and basically negotiate between the two of them for how things work and how they perform. So pretty exciting time. And in an industry that employs millions of people, this changed very little over the last couple of decades. Architectures have changed, chipsets have changed, software has changed, but the human beings interaction with those systems has not changed a lot. Right, I mean, in the networking industries, people still brag about CLI. It's pretty basic stuff. But, and they have to because of the heterogeneity, the distributed and dynamic nature of computing. And then obviously the heterogeneity, you're the, you know, the godfather of super cloud and many cloud and hybrid crowd and multi cloud. Well, those are all about all these different environments that are now kind of banging into each other and they can't just have effectively human middleware manage them by themselves. So pretty exciting. And then obviously compounded about the enormous amount of data that is making its way into organizations through AI. That's a great, great summary. I think let's unpack some of that out of the box there because you got, you mentioned humans in that AI middleware. I mean, middleware is a concept that goes back to the old early days of computer industry, you know, hardware, applications and then middleware to kind of run things. That's just started to have distributed computing, mini computers, lands and whatnot and, you know, networking, internet working and TCPIP, create all that standards. Now today, the idea of architecture shifting is interesting and it's interesting that IT hasn't changed. I mean, we're talking about platform engineering, some of the stuff from theCUBE. It's like, wow, you got to be really engineering smart to do that. Not an IT person potentially is more operating. You got an operator running some vSphere, some VMware and you got alpha engineers working on hard core, re-architecting like large scale infrastructure. So clouds, for instance, like Amazon Web Services and Azure. And then you go, okay, well, on-premise has great for machine learning and AI and you got Edge. I mean, that's a data problem that's kind of mind boggling. If you're using an old data warehouse, who runs those? And then it's like, okay, then, okay, how do I mesh? One, how do I figure out what I want to do?  Well, everything gets compounded. And I'll give you a great example. The size of the datasets that you see in the kind of the large language model, the chat GPT architecture. So you'd say, hey, this is really good. It can write a marketing paragraph or sales paragraph or three pages of documentation for me. Of course, I have to burn down a small forest in the Amazon to run the computing capability to do that. So we're still in this kind of building phase of architectures, which large language models will run in on the monolithic platforms like chat or Google or whatever Amazon and Microsoft are building, which will be open source. Who's going to be the red hats of AI because one people don't want to pay the tax, not everybody can, and they are very sophisticated and a lot of the open source models are really, really, really good. And fast too. And fast and don't necessarily have to consume running the whole model just to run a query. And your point about burning down the rain forest, whatever you said, that's implying obviously the resource required to run a basic query on chat GPT. Or drain Lake Tahoe to make the transition. And the point there for the folks watching and listening is there's been documented that a to run a chat query on chat GPT just requires massive amounts of power and cooling. And yeah, enormous amount of water. So I think you'll start to see kind of distribution architecturally because there's not one size fits all. Some things can be done on an open source model that's fairly efficient to run. And I'll run that in my organization actually will be running on a, but I'm not missing it. The guys in Cupertino tell you it's going to run on your Mac or your iPhone. So that's going to be a lot smaller model and that's going to have to plug in all the time. Now that battery is not going to be around even though the power on the chips are pretty good. So, you know, there's, so kind of everything is up in the air, right? We have the underlying from the physical chip levels, right? It's been a really great run for Nvidia, but obviously there's going to be competition. The centralized versus distributed edge, you know, hybrid, right? That's all up in the air. What the apps can do. But the most exciting part, I think of all of this to your earlier question is I don't actually have to be that same kind of expert. While people talk about a lot of things you can do with, you know, I can create funny videos or I can have a picture of Gandalf playing at a Bruce Springsteen concert and on mid-journey, I can do all those fun things. But what I can also do is I can actually transition code. I can say, here's a code base. Rewrite it in Python or pick a more, you know, a new language, I can translate. It solves the cobalt problem. We would have didn't have it for the year 2000. There was a lot of good jobs, right? And a lot of us, I mean, I worked at Cisco. We were up till two in the morning making sure all the networks didn't go down and then we started drinking, right? But yeah, but we sold an enormous amount of equipment to even just deal with that. So the organization's consumption of AI because you can do things in natural language is going to accelerate. So there's gonna be a lot more people using it than the people who provide the underlying plumbing and capabilities underneath it are going to have to shift to do that. And so you see, and we were talking before we came on camera to get this out there now, this is a good point to talk about it. That AI will replace those jobs or elevate those jobs in IT that are mundane and are quite frankly grunt tasks or rock fetches as Dave Vellante calls them to make the machines run that, to shift the humans either into a new role or just automate away completely their role in running middleware and configuring and running networks. I don't know if it's a net or gross job killer but there are hundreds of thousands of open jobs in IT. You cannot run a business in any industry anymore unless your computing infrastructure is supporting it.  So the ability to operate faster could be one of the, and more efficiently and honestly, with fewer errors could be one of the great benefits. So for the, when you- An incentive for executives to fund and or figure out quickly or give the green light to engineers or people to figure out how to deploy AI to move on that opportunity. Right. So you know that by background, you may remember or you've probably purposely forget for good reason your own sanity by training I'm an economist and I always look at- I didn't forget I was gonna bring that up. I always look at how people spend. So if you look at IT spending, for the most part for the last decade, I mean there's been some spikes on and off, it's been in the low single digits. And so if you think about it, technology spending has been at the rate of in the last couple of years under the rate of inflation. So when you grow slower than the rate of inflation, you're actually shrinking. And that to me tells me one thing, the people in charge of organizations don't believe because if not they would be spending faster than inflation. So the myth that IT accelerates and drives your business, it's gone from that to this necessary tax I have to pay to keep the lights on and things running. For the first time in a decade and why I'm actually very excited about enterprise AI is that it can actually affect how products are built, not the back office, not the billing, not the marketing, not the paper flow, not the accounting, but the actual physical processes. I'll give you a great example. Last week was the GPM conference. One of our companies that we're investing. It's GPM. Oh wow, you've got another industry. JPM Morgan Chase, the largest health tech conference in the country. It's in San Francisco every week. One of our companies, Recursion Pharmaceutical, announced their large language model, which is an engine for small molecule, therapeutic and drug development. They have a model that they can plug inputs into, which allow them to come up with cures of cancer and therapeutics faster than they did when they had lab scientists and analysts. Yeah, that's great leverage. It's great leverage. They have data, right? They have an index. They have a huge proprietary massive data mode on small molecule biology. But now the technology can actually drive what they're building, which is actually vaccines and therapies. Not doing the back office and making sure Mary checked in and put in the hours and the PTO and all the things you think about. So we're finally getting to this kind of terminator phase where the technology, because of AI, is actually being infused into the products and services people are building and that they are primary. So we call that tech bio instead of biotech. I have an investment in a surgical navigation company that just had FDA approval that's operating on patients called Proprio. It is the Google Maps for surgery. It guides the surgeon in real time. It's like Waze. It's a little slow. It is actually Waze. Oh, we got to do a triple bypass while we're in there. Yeah, well, we're not quite on time. We're in the spine today, but we're working. So this is a fundamental shift, which actually makes technology more important. Well, this is why I want you here, because you're in your career. You've always been kind of at the early stages of companies and or Waze, wireless networking, networking, wireless. Cyber. Cyber. I mean, everything, you know. That's the DC with Nasera. Usually scar tissue comes with that too. And they're learnings. We are in another emergency. I'm only 25 years old. Look at the lines of my eyes. We're in emerging market now with Waze. So looking back and taking all that expertise, what is the critical success? Why are people getting excited? Because what you're talking about is a redefinition of workflows. So now that you have AI now part of the application process, you still need developers to code the apps. I agree.  Workflow is the IT combinational differences. This is a, I guess you could call it workflow. Or workflow or process, whatever. Process, yes. Something that's happening for me, the developer or app person. Or the biologist. Yeah, the user. Working at recursion now uses AI. I mean, yeah, they have a laptop they take notes on. But then the language model says, I'll give you an example. There's another company in our portfolio called Unlearn. They build digital twins. What that means is why instead of experimenting on Primate, they can actually run the lab experiment in a digital twin. They can physically simulate those things going on. To tie this back to Myst, just to prove I do have some memory for you, John. Myst was the first company that built predictive algorithms for wireless and edge networks. And they would see patterns.  They knew when people moved around. And they were able to then reconfigure the network ahead of time based on that. And then obviously in real time. So the human behavior that it saw moving, packets into the network was actually being studied and they create their own version of a digital twin. This is why it was such a valuable piece of that because when you get to running, thinking about- I know AWS used them at re-invent. Of large scale events also are interesting too. And by the way, they also used my company Evolve for physical security. So you don't need as many security guards. 3,000 people an hour can walk through and they don't have to empty their bags and pockets. So things that used people. I always wondered why that worked. Because I have a bag and I didn't even get pulled over.  It reconstructs your body and it knows whether you have an iPhone or a gun in your pocket. And that's what the algorithms and it learns all the time about the changes. So it allows people to go fast and it sees it into your bag as well. It uses an array of sensors and magnetics and but also- So more data the better it gets. Yes. And that is the answer to everything. The more data, the better it gets. And what you wind up is that companies as opposed to having just technology modes, they're all going to have data modes. So you're going to compete on your data set as much as you're going to compete on your technology. We need Jerry Chen here, because he's the mode king. The mode king. The castles in the cloud. So again, this data is the new modes. I love that. That is definitely happening. Now here's the little haymaker I'm going to throw out there. Data traditionally has been in construct and distributing as a database driven and Oracle and all the success there. Data warehouse has been out there. Snowflakes got the data club up there actually. Got to lock in. Data bricks is out there. So now, okay, this flips the script. So if I'm going to have like good carbon emission computing, not burning forests down to do queries, you're going to have to have iPhones running inference. You're going to have data that needs to be exposed everywhere. That flips the script on data management and data availability. Is it highly available or high availability? So all these things becoming into play. So what's your vision on how you see that? Cause you guys do a lot of big moonshot investments at DCVC where you're a firm. And so you've seen machine learning for years. So it's like, what's the script on the data layer? How does someone create a data model where an app developer can write a code so that if I'm at the edge of the network, it knows a lot of things from multiple databases instantly. It's a great question. The answer comes through is how does the model work? Cause the model is the intelligence and how does the model onboard it? So you may have seen one of our investments was a company called Mosaic ML. It was acquired by Databricks for $1.3 billion, right? Great founder, former Intel. Yeah, fantastic, right? And we've backed him before. I mean, it's a prior company. But what's- Was he sold to Intel? She sold Intel, he's got her out. He's great. He's an alumni by the way too. Naveen is terrific, really brilliant. But what Naveen solves for Databricks is how do I make it easier to onboard the model? So you're talking about how do I use the data? Part of that is how do I onboard the model? And do I have a structure to bring that data into the Databricks engine for creating those models? So what I would say is that we're still in the early early, despite all the hype, we're still in the early phases of building out the architecture for all of this data, making it useful and then making it useful for a model. And what is a model? A model is a version of how the human brain works, how it processes things, how it gets the synthesis and then ultimately brings you answers. When you do due diligence on a company, obviously, some people are very light AI, I mean, we call our cube AI, cube AI and essentially transcripts, it's got some... You know that I've got 70 something clips, right? You knew right away, right? Well, that was the data lake. I just thought it was a query to the data lake, but the AI actually has... Made that very easy for you to query, right? Well, we have now perplexity kind of experience where you can type in a query, what is, how do you get the results with multimodal sources? But it's not real AI yet because we're just ingesting and we're just doing embeddings. It's more rag, it's, you know, retrieval, but it's essentially a wrapper, right? So we're using AI, open AI, Anthropa, we're expecting all the different models. That's not yet true AI, although it's a good app. So I was, and Gensli was against AI, I thought they were kind of trivial, but it's almost like a web page. You're in the web days. If you had a web page, you're in the web. You're not actually a web company, but you have a web page. But the thing that's a little different here is, so you know that I spent two years on the board of LLM and AI, which is Yashua with Benjio's company. So Yashua with Benjio, Eve Lacoon, they were students at Gert Jeffrey Hinton's, they're inventors of what we call AI. They created neural networking. Yeah, I wasn't going to the whiteboard correcting the alagos, trust me, I was learning.  You know, neural networks and AI has blind spots. It has lack of judgment, right? But there's an element of reasoning in good AI where there's some meta reasoning or some reasoning, not just retrieval. It's not just, it does, it does reason. That's the whole, why they call it neural.  You know, like somebody did to me. Yeah, and I can use some help on that. And those parts are still being built. And so the, what you're seeing right now is the, you know, the beginning. Will data sets merge and have fusion? If I have a great cube linguistic model around B2B jargon, you know, I have all the jargon of the cube interviews. So one of my motes is I have good word combinations, but I'm not going to be the comprehensive, large language model. I don't have enough data to do anything, but maybe I integrate with the model. Do you see models talking to each other and passing parameters and learning from each other? Yeah, I mean, all the time, you know, one of the things one of my companies did, they were looking at, they were doing AI work a couple of years ago and retail, they bought out 20 years of serious point of sale information. They told you what was sold, what time of day and where. Right? So you can, that was used in training a larger model. So there are data sets that you could acquire. Like I suppose, you know, you could buy the, you can buy the Andrew Ross Sorkin CNBC data model and you're giving perspective, he gives perspectives on the market, you give perspectives on the market. You could be merging those two.  Absolutely. He rolls on the enterprise. Like Andrew, you're stepping the side. So yeah, no, but I think, you know, there's enormous activity going on. You know there's enormous investment, there's enormous hype, but there is real fundamental change on how things are done and there are good data modes and then there are kind of some worthless data modes. How should entrepreneurs and business executives and or developers or people who are leaning into AI to get on the right side of this wave, to ride the wave and to create value? How should they be thinking about what they're building from a durability standpoint, sustainable standpoint, funding standpoint? What's your take? Because you know there's a lot of noise right now and I know a bunch of startups in this market that are kind of in that net of bad companies that are actually trying to fight their way to get a path. There's a lot of noise around companies that are walking dead in the kind of the last model seeing the numbers there, but there's still a lot of promise. So there's a lot of entrepreneurs on the street right now and business people scratching their heads saying, I got to get out of this. I want to get to the right side of the street here on the AI. I want to be on the sunny side, not the dark side. That's failing. What's your advice to them? What should they do to demonstrate how they should tell the story? Is there any tips? Well, I mean, you know, there's a couple of things that look, today's Monday, right? So I, before I came over, we were in our deal review. I serve four deals. They're all about AI. That's all we see these days. The first one is are you actually solving something really matters? Like I don't need the 13th business plan to tell me how to write a paragraph better. Like I'm going to be better than Grammarly. Here's why, right?  Right? The spell check on Microsoft Word will be the AI writer. Clippy becomes a company.  And then number two, is it real? I mean, it's not any different than anything else, right? Is it real and pressing that, you know, if I don't solve this, like, you know, the world is less better off? Will people absolutely rush to want to use it immediately? Is this a, I mean, there's the old adage of the aspirin and the vitamin. It's true in AI as well, right? And steroid too, the growth thing. And by the way, is it going to be efficient?  The most amazing thing about open AI is they did $1.6 billion of revenue last year and you're sitting there with me. I'm paying $20 a month to, you know, to get a better search than Google or have somebody write a paragraph for me. So they have built a, and obviously there's, I want to use your experience game. Yeah. Big time. Except it doesn't work for everything. Yeah, exactly. It works if I have a paragraph. Once if I need a table and I need to see things side by side. So if I'm in IT and I'm saying, I'm evaluating 12 products, I don't want to read 14 pages about it. I want to see them beside by side. I want to see, you know, what are the features and capabilities they have? So there's still plenty of, you know, where to go on the UX side. But they did make it bone dry, simple. Well, I mean, this is why the web is a good analogy because the web was nascent early and it was like primitive, but you didn't need to solve the connectivity problem because that was getting better as more people came online, but the experience got better. And you can argue that the AI is good enough. Well, cool. I'm writing some summaries. It does help, help me. And this is my next question, which is, you know, in all these major inflection points, there's an element of a pattern. If you can reduce the steps it takes to do something, okay, and it's easy to understand and use, it works. And so in this case, ChatGPT, it helps me get some content out there. Also goes through email lists. It cleans up spreadsheets. You can tell- Oh, it does all kinds of really marvelous things and apparently- A lot of grunt work, a lot of heavy lifting as they say. So yeah, there is always- Small utility. So in that case, Chat and some AI is done what technology has done since IBM launched the 360 in the 1960s. So what is that? 60 years ago? It's getting to be a long time. It removes crummy, low-end manual tasks through automation. So technology has always used automation to basically speed up things and make things happen faster. Sometimes it works really well. Sometimes it's actually worse. You know, we've all been through this where you've written 13 drafts of something and if you had written it down with a pencil and a paper and done it right the first time. So you're automating and I'm spell-checking and I'm cutting and pasting and I'm shipping and all these people but I'm not actually thinking.  I always love like all of the review sites and I always call this the tragedy of tripadvisor.com or Yelp. And you say, hey, I'm gonna go to this cool restaurant down the block from the Cube studio. Looks really good. I love Moroccan food. And I read the first 10 reviews and like five say it's great and five say it's lousy, wisdom of the crowd, data moat coming together. But none of them say whether I will actually care. And you know, like, I mean, the reason why people tune into the Cube is they see guidance from you and the people you bring in that help them in decision making. So just aggregating data and presenting it efficiently is a piece of that. But then there's perspective and we're not yet at the perspective side. If something is very technical and very, you know, very scientific, having a clean data set, accurately presented, sourced massively is a fantastic need. But it doesn't tell you whether you should do it or not. Well, this is where your view is. I like this angle of increasing the productivity to get to value, right? And so the time to value can be accelerated on that next step. That's what's coming. That's what's coming. So can it actually reflect the question you're trying to answer, the decision you're trying to make or the data that you're trying to say is good or bad? Because AI doesn't know if something's good or bad. It doesn't have context. We're a long way, I think, from real context in these areas. But if I'm running a network and you're saying this is gonna overload the network and this is not, I don't need a lot more context. It's like not doing it's a good thing, reconfigure it. So MIST is like, okay, change the channel assignments, change the transmit power, be able to bring on this large crowd at this time, distribute the traffic. That's what it did. Because the context was just make it perform. But when the issue is, should I take that medication or not? Should I make this investment decision or not? Yeah, different story. That's where the intelligence needs to be. And that is the part, we're not yet at the quite a determinator phase of AI. We're the terminators. It is better to kill all the people to keep the planet safe. Yeah, you know, that's the meme, the guy's job is to pull the plug, right? Yes, I think so. The new platform engineering job. Al, great to have you on. Well, to wrap up, great chat, very podcast style. Love the conversation. You're awesome. As you look at the HPE buying Juniper, it speaks to the consolidation. You got a perspective of management, make that acquisition work. And we've got the competitors like Cisco out there, looking at this and maybe it's opportunity while they figure this out. But it's also there's a customer perspective. So as this industry is evolving and with this inflection point emerging around how people will do their jobs, how they will consume technology and whatnot, what are people thinking? I mean, how do you see that? I mean, what does HP do right now? How's that going to play out? How do you see that playing out? And how do you see customers reacting to this kind of big mega acquisition? Because it's consolidation. It's a lot like Broadcom. Well, look, there was a news, I think today about synopsis making a $35 billion acquisition in the tool space, like for building steppers and underlying, you know, goes into building all of this tech. So I think when you shift through errs of technology, there's always consolidation, right? Because what it does is it says, okay, we're kind of at the point that things are starting to become commoditized. So critical mass, scale, cost, reliability, the things that you expect from commodities. And I think a lot of the traditional client server to cloud industry is kind of in that phase, right? But now there's this new phase. So I think, you know, look, I think traditionally us folks who've worked in tech have seen this brand identification. I'm a pure person. No, I'm a Hitachi, right? You know, like in the storage, right? I'm an Amazon, I'm a Microsoft. I'm an Amazon, I'm a Microsoft.  And then, you know, there were people I missed, but I'm my HP. So, you know, we'll be watching very carefully. It's an interesting culture. I mean, in networking, you can't please everybody. I mean... Well, no, I mean... It's kind of loyal, loyal base. So does Cisco. When we sold airspace to Cisco, I remember doing the first technical advisory board. So our biggest wireless customers come in and I give them the new roadmap of the two companies and they go, well, we love these airspace features. When are we gonna get this on our legacy Cisco equipment? I go, how about never? Is never good for you? And they were furious. I go, what do you mean? I said, well, look, if I try to write features for two different platforms to do the same thing, you're gonna get zero innovation. So you have to make a choice. Now we'll help you migrate. There are some things. If I'm a customer, I'll go to the cloud and I'll run Juniper switches in the cloud. Well, I will, as long as it's cost-effective. So the other thing is that right now cloud and on-prem... I'd be worried if I was a customer. I'd be like, okay, I wanna make... Cause Juniper and HP, I mean, there's overlap there, but also misses a crown jewel, right?  Do they lose people? Do they keep people? What's the migration look like? What a customer? People after integration into a large company? Never happens. Never happens. We'll be watching. No, yeah. So I think, you know... That's a big concern. It is, but for the ecosystem, there's a lot of really brilliant people who come out that folks like me get to invest in, in the future. I mean, why don't we just say the quiet part out loud? And so, you know, I think they'll make HP better and some HP customers will benefit.  Juniper really did an amazing job letting Mr. Run Mist became a driving force inside of Juniper. That may, who knows, that may be what happens inside of HP. Like Juniper may be the company that gives HP at second, when third or fourth, or 18 wins. Yeah, the RUPA has some gaps, a lot of complaints on the RUPA side, so... Okay, closing out. I was in that war too in the beginning. Final question as we wrap up.  How does this next 12, 24 months look like as people who are out there trying to figure out, okay, AI for good, AI for guardrails, and what is AI? How should people be thinking and framing in their mental model how to look at the opportunities with AI? And what are some of the cautions, if any, that people need to rent? Now, my opinion is, let chaos reign in the face. I look at your question the way people looked at SAS, the way they looked at Bandy Off 18, 20 years ago, and the way they looked at Andy Jassy and Amazon. And you remember like, hey, this SAS thing, we'll keep an eye on it. It's perfectly okay for salesmen, people don't buy package software anywhere, right? You buy it at SAS. And everyone, when Amazon Web Services was just doing S3, everyone says, oh, no one's gonna put mission-critical workloads in that thing, right? So I think people, this is an inevitable move. And it is going to affect everything. It is so powerful. And this is not a hype statement. This is going to consume a great deal of technology that we rely on as both individuals and as businesses. And there is timing that's appropriate. It's like, if you bought the model, if you bought the roadster from Elon Musk when it came out, it was probably that it broke down on Sand Hill Road, I used to see them. I was an early buyer of the Model S. It was pretty good. And then Model 3, just flawless, right? So people make their decisions on when to adopt based on when they're ready to adopt. But the adoption is going to be in everything.  Yeah, I loved it. Okay, when's the last time you drove a stick shift car? I can't remember. That is the point. That's not available. I love to buy one. 75% of the cars in Europe, you can buy one, but there aren't as many. But there was a point in time that it just doesn't make any sense. It's coming to tech. The tech industry, again, on the human side, I think it's going to be massive transformation. Again, this wave is coming. It's exciting. I personally think the entrepreneurial equation is going to be significant. I think this chapter is going to close very quickly of the overfunded zero interest rate period. And it's going to move quickly to value creation, open standards are going to swing back with open social dimensions for you those. We're watching those on theCUBE. And of course, the ecosystem, the new wind system of the crowds are going to be part of this. Now the data is going to be available. And again, The talent that entrepreneurs that we see now in AI, kind of like Gen AI, there was, I don't know, it was last one, Gen Z. The next gen is Gen AI. I think we're going back to the alphabet in front of the alphabet. That includes us old guys who have been through multiple cycles. There's a lot of older entrepreneurs now coming out. I'm seeing, I mean, comment on that. It's not just the young in the 20s. I just funded two people in their fifties that are unbelievably talented. And it's an AI play. And so what you see now is because of the disruption. It's just some, a lot of the older executives have systems thinking. That's right. That's a big part of this, isn't it? Yeah, but not everyone has the ability to completely decide on how to blow things up. That's, that is the young person. Revolution is here, Allen. Great to have you on. Great chat as always. Again, podcast style. Great, great masterclass there. Great insight. Thanks for coming on. Pleasure to have you. I'll come here. He's a general partner at DCVC. He's sitting on the other side of the table writing big fat checks for deep tech AI. And, you know, really moonshot projects that are now part of the mainstream. Once was once a moonshot is now a real deal with AI again. The world will be changing very rapidly. The scripts are flipping. Entrepreneurs in charge, developers in charge. If you have a data moat, that's the playbook. Thanks for watching.


Shoot down a temperature like this. So keep your distance. Yes, sir Let's stay focused watch your sectors There's the communications outpost Could be the missing troopers. Let's check it out your eyes in the sky. So Let's go six night noble team spread out watch the approach Structure point three four looks clear from this angle Distress beacons coming from just south of your commander. We're close Roger that eyes peel make out any ID negative, but it's military Why are we not seeing explosives residue noble three, can you confirm any EX residue in the area? It looks like there's nothing here. Let's move on Smoke at the next structure boss circle west and check it out noble team You have permission to engage the be selected. You don't need a telegraph of presence Noble six move into the house digs in the structure ahead They're not rebels their farmers look at them ask them what they're doing here meet Christ the kid But then my cutto me in Holly hiding sir Taking up idea as some city gold is us neighbors were attacked last night here at that with your screens Gunfire stop around sunrise Says something in the field Killed his son something commander be advised. I'm reading heat signatures in that structure directly east of your position over Copy that get them back inside Osmont on Bethlehem getting Noble team double-timing What do you see over? We've got military casualties two of the missing troopers Looks like they were interrogated It's messy see anything


The trigonometric functions and the laws of sine and cosine allow us to do what's known as solving a triangle Solving a triangle is based on a couple of important ideas from geometry. A triangle may be uniquely determined if we know all three sides. This is sometimes referred to as side, side, side, SSS, two angles and the common side, angle, side, angle, two angles and a side, angle, angle, side, and two sides and the included angle, side, angle, side. We say that the triangle is solved once we know the lengths of all three sides and the measures of all three angles. So let's take a triangle like this where the measure of A is 47 degrees, the measure of B is 17, and the length of the side AB is 8 units. Let's solve the triangle. In other words, we want to find the measure of all three angles and the lengths of all three sides. Well, let's draw a picture. Now the picture is not part of the portfolio. We're going to use to enter art school. Thank goodness. But rather it's a way of organizing all of our information. And since this is triangle ABC, we should probably label the vertices ABC, then set down the angles and lengths that we know. Angle A is 47 degrees, angle B is 17 degrees, and the length of side AB is 8 units. It will also be convenient to remember that we can label these sides by the angle they're across from.  And remember, we're trying to find all three angles and all three sides, and we might start by noting that we have the angle A, B, and the length C. So based on this, we see that we need to know two side lengths and one angle. So how do we find them? Well, to begin with, one useful theorem is that the sums of the measures of the three angles in a triangle is 180 degrees, which means that if we know two of the angles, and we do, we can find the third angle. And so let's set that up. We know that the sum of the measures is 180 degrees. We know the measure of angle A and the measure of angle B, so let's substitute that in and solve for the measure of angle C. And if it's not written down, it didn't happen. How about the lengths of the sides A and B? For that, we have two theorems that relate side lengths and angles, the law of sines, and the law of cosines. So the law of cosines requires us to know two sides and an angle, but we only know one side. And so we see if we can use the law of sines. Since we have the measure of angle C and the side length C and the measure of angle A, we can find the side length of A using the law of sines. So substituting our values in. Now, while we could find sine of 116 and sine of 47 degrees, let's solve for A first so we don't have to carry around a bunch of messy decimals. So solving for A gives us, and now we can find sine of 47 degrees and sine of 116 degrees. And if it's not written down, it didn't happen. And now we want to find the length of B. Now, for using the law of sines, we have to use this angle 17 degrees, but we have two choices. We can either use this length C equals 8 and angle C equals 116 degrees, or this side length A about 6.5096 and the angle A 47 degrees. To decide which to use, a useful idea to keep in mind is use the numbers that you trust the most. In this case, this side length C equals 8. We have to trust because we're given that as part of the problem. If we don't trust this number, we can't solve the problem. So we'll want to use this side length C and this angle 116 degrees to set up our formula for the law of sines. Solving for B and computing gives us our third side length. And now we have all three angles and all three sides, and we have solved the triangle. Or have we? Well, probably if we did all of our computations correct. And here it's useful to do at least one check, which is based on the following theorem. The longest side in a triangle is opposite the largest angle, and the smallest is opposite the smallest angle. So if we take a look at our three angles, the largest angle is C, and the side length is 8, and we verify that this is actually the longest side of the triangle. Likewise, the smallest angle is B, and the side across from it is also the shortest side of the triangle. While this is no guarantee we've done all of our computations perfectly correctly, it tends to catch very serious errors like not having your calculator in the proper mode. Another one of the UD cases is where we have all three sides of the triangle. So for example, maybe we want to solve a triangle with sides of length 8, 9, and 13. So let's go ahead and sketch a triangle where the sides have length 8, 9, and 13. Now it doesn't really matter which vertex we call A, B, and C, and we should always indicate the side opposite with the lowercase version of the vertex. To determine how to proceed, we can pick any formula and see if we can use it. So what formulas do we know? Well, we know the sum of the angles in a triangle, we know the three equations that correspond to the law of sines, we know the Pythagorean theorem, and we know the law of cosines. First off, because this is not guaranteed to be a right triangle, we can't use the Pythagorean theorem. Next, we don't know any of the angles in this triangle, so this sum of the angles at 180 degrees isn't useful. There are too many unknowns in this equation. How about our law of sines equations? This first equation requires us to know the measures of the angles A and B, as well as the side lengths A and B. And since we don't know the measures of any angle, we have two unknowns in this equation, and we can't solve it. The same argument applies for the second equation. We don't know the measures of angle B and C, and so there are too many unknowns in this equation. On the other hand, in this equation, oh wait, we still don't know the measure of angle A and C, what about this equation? Well here, we know the lengths of all three sides, A, B, and C, so the only unknown in this equation is the measure of this angle C, and that means this is the equation we want to start with. So we have A, B, and C, we can use the law of cosines. Substituting those values in, then solving for C gives us, well now we have two sides at an angle, which means we can use the law of sines. So we'll use our first equation from the law of sines, substitute in our values, and again we get down to the point where the sine of some angle is approximately some numerical value. So again, we have to use the inverse sine function to find our angle is about 36.7988 degrees. Now we could do the same thing to find this measure of angle B, but we might as well use our simpler relationship, the sum of the three angles is 180 degrees, and we know two of the angles already. So we'll substitute those values in, and solve for B. And it's worth doing a quick check. We want to make sure that the longest side is across from the largest angle, and the shortest side should be across from the smallest angle.