 and Santa Clara for the Velocity Conference, Riley Media's Velocity Conference. This is Silicon Angles theCUBE, our flagship program. We go out to the events, extract a signal from the noise. I'm John Furrier, the founder of Silicon Angle. I'm joined by my co-host. Hi everybody, I'm Dave Vellante at Wikibon.org. Nicholas Zekis is here. He's a staff software engineer at Box. Nicholas, welcome to theCUBE. Thanks for having me. Yeah, so you're welcome. So we're here at Velocity, your peeps. What's the vibe so far? I think there's a lot of energy, a lot of excitement as there always is every year. I think this is one of the conferences where when you hang out in the hallway in between the talks, you get to learn just about as much as you do when you're in the talks, because there's so much cross conversation going on, people sharing ideas and experiences. It's just a lot of fun. Yeah, so I appreciate, by the way, getting dressed up to come on theCUBE. Most guys don't know what this is at this conference. So what are some of the conversations that you've been hearing today in the hallway that have been interesting to you? Well, as you're walking around, you hear a lot of mummals of la-la-la performance, and then you hear like ma-la-la-la, oh, JavaScript, which is always interesting to me, because that's what I spend a lot of my time working on. There's a lot having to do with the amount of JavaScript people are using and the JavaScript solutions that they're using, because there's a lot of libraries out there and people say, oh, well, I'm using Angular, oh, well, we ran into these sort of problems and here's how we solved them. There's a fair amount of that going on. There's a fair amount of discussion about mobile performance, since that's something that is still really new and something that we're all dealing with just kind of as a fresh problem. So a lot of talks about some of the keynotes this morning and the performance tools related to mobile that were there. Some of the challenges about going over 3G versus LTE just a lot of stuff along those lines. The recurring theme on Twitter was seeing a lot of tweets coming in here, but the recurring theme in most of the talks here at Velocity is the perception of speed and user experience is just as actually important as the system speed. Do you agree with that? Absolutely. I think that perception is sometimes more important than reality, that if you can make people believe that what they're seeing is faster than what it actually is, then they're happier and you can do that by doing a few different types of tricks. And one of those is just making sure that you understand what your user is looking to do when they come to you and making sure that they can do that as quickly as possible. So I got to ask Joshly Box, I still call them box.net, they changed the name to box, but Mark Hawkins and I always talk about box.net, it's kind of like branded in our head. They have challenges too, it's cloud-based and it's now they're going into the enterprise, it's mess-out-lays related, but more importantly, you worked at Yahoo front page and so that's sacred cow for Yahoo. I mean, that's not like no one just, it's not like Mark Zuckerberg breaks stuff and then you don't do that when you have about 50 million people or more hitting that thing a day or a minute, whatever the stats are, it's massive. So you've got to really focus on page load, utility speed, that perception is one angle. So you got, in managing that every day, I mean, how do you do that? Just take us through some of the design things you've done and just philosophies and give some examples of things that kicked ass and give some examples of where you had a, oh boy, you know, uh-oh, a break or so then, what were the consequences? Yeah, there's, so I think that everything starts with analytics is that it's hard to know if you actually are slow or not if you don't have anything that you're watching all the time and I can visit a page today right now on my laptop and say like, wow, that's really slow and you using a different laptop might say, wow, that's actually really fast and so getting to a good definition of what is fast versus what is slow is the first important step. Let's get our analytics in there, let's figure out what our important metrics are and then once we have that, let's figure out are we happy with those or not and some of that is just basically like, you know, if the time you spend on the server, rendering a page is like two or three seconds, you should be unhappy with that, that's not good enough. However, then you put that in front of real users and you see what their reactions are, is this fast, is this slow and get that feedback and some of the interesting things that we learned are that there's a lot that you can do with perception to tweak whether things seem fast or slow and one of those was if you have a very large blank space on your page and people are staring at that for a second, it's gonna seem slow, whereas if you're able to make a blank space that doesn't look as empty, so you actually have some frames in there, you have even like a loading spinner, that makes it seem not as fast and so we did a lot of experiments as we were trying to dynamically load more content onto the page where at first we started out with this giant blank area and people said, wow, that seems slow and we figured out ways to make it seem like it wasn't as big of a blank area without changing any of the actual performance and put it in front of people and then they came back and said that seems much faster. So take us through analytics, I mean monitoring and app monitoring and analytics is always kind of like, is it big data? Is it a little bit different? Both, when you hear A-B testing, everyone talks about A-B testing, it's a way to get to validation on that. So what is the current standard or momentum around the current app and monitoring analytics? What are the frameworks and things that are being used? Well, there's a lot of different tools but they all fundamentally do the same thing and they're measuring different points in time from delivering your web app from the server to the browser. And so one of the most important pieces of data that we look at with the web application is how long does it take to get to the onload event? So how long before everything that's on the page is completely loaded so people can start using the application? And a lot of people spend a lot of time looking at that specifically. One of the tools that comes from another guy who was at Yahoo, Philip Telus, is called Boomerang, he works for SOASTA now. And that basically is a technology that helps you measure not only onload time but a lot of the other associated times between that. So how long does it actually take for a DNS lookup? How long does it take before you start to get data to the client after making the initial request? And how long does it take for JavaScript to load? How long does it take for the images to load? And things like that. I want to get your perspective on something because we had some earlier conversations this morning and some of the conversations in the hallways have been about, hey, you know what? Velocity conference isn't about the cloud only. It's not about just UX and front end development although they got fluent for that. Probably a field day for you to kind of hang out a fluent given all the JavaScript focus. But it's really a hybrid integration of design, decision making at the infrastructure cloud or cloud ops or dev ops, what I want to call it and the app side. So it's converging and pretty clear that that's a trend. So we probably agree with that. But I want to ask you though in context of things like Node, right? Node has opened up the kimono for creativity because you can have low latency discussion to say the browser. But one thing that wasn't talked about a lot at Fluent was WebSockets, right? So WebSockets has been around. It's not like a new thing, but with browser, native browser thing, you're seeing a much more reliance on that kind of linkage or that connector for lack of a better description. So okay, you got Node, you got JavaScript on the server, you got native browser. Where's this going? Now from your perspective, you've been the Yahoo guy on the front page. Do you want that sacred cow and the critical nature of it? Speed, every little ounce of energy you can squeeze out of that makes a difference in the business model. So okay, given you have that and you were in this new world, what does this mean? What is this all the node, trend, WebSockets, native browser velocity? Tie it all together for us. Yeah, I think the most interesting part of that is that you can write one language and build a complete stack out of it. And that's freeing up a lot of people because there were engineers that loved JavaScript, but were not as enamored with the browser side of it because browsers are really hard to deal with. And there are dozens at any point in time. They all behave slightly differently. And that's kind of a pain. And there is something nice about being on the server where you control that environment completely and you know exactly what version of Node you're going to be using, how much memory you have and all of the other aspects of the system. And so now for those people, and I worked with a few of them, we said, you know, I love JavaScript. I just don't want to deal with that HTML and CSS stuff. Now there's actually an opportunity to have a really awesome fulfilling job by doing Node on the server. And that allows you to bring a lot of knowledge about JavaScript over into the server world that can make a huge difference. Things that are very hard to do with languages like PHP and Java are actually very easy to do with JavaScript. And when you have Node compiling JavaScript down into byte code, then it can run just as fast, if not faster than those. So I think that we're seeing a bit of an evolution where people who started out as web developers are starting to say, you know what? My passion is actually on what's going on in the server and getting data to the browser, but now I can use a tool that I'm familiar with to do it. So I got to ask you the kind of fundamental elementary question, which is good to have on the archives. There are a lot of new developers out there. We were commenting earlier, like, you know, the new, the news for VC funding for entrepreneurs and the new series A is the new series B. It was just written by Andrews and Horowitz. Saw that on the web. And meaning they can get some seed funding and then they can get to scale pretty quick. So that means you've got to make some good design decisions, even as a small scale, not just hyper scale. So if you do that right, you could really cross over and not be one of those abandoned startups. Or if you're an IT guy and you're doing, hey, I want to roll out some mobile apps, I want to do it right. So for the folks out there that are doing, making design decisions around UX and UI, for say a mobile app that has a node or something else in it, and they want to make it fast, they want to do some stuff, what would you say to them? What would you share with them? As key things to think about, whether it's features, functionality, platform stack, et cetera, what's your advice? I think the most important thing is to understand your users. So why are they coming to you and what are they attempting to do? And then you make the fast path, whatever they're there to do. So I like to use the example, like Yahoo Mail. If I'm logging into Yahoo Mail, then chances are, I'm either wanting to read an email that somebody sent me, or I want to write a new email to somebody. Or you might want to just see an ad. That's all I'm saying. There are plenty of places to do that on the internet. We're not going to have that. I had to dig on Yahoo Mail. So I had to do it. And as long as you can do that, as long as your users can do that when they come in, they're going to feel like the experience is pretty fast. So making sure that you really understand what user expectation is when they're coming to your app I think is most important. So fast path in the right experience. Yeah, fast path in the most important thing that they're coming, that they're coming to you for. And then after that, you're free to do pretty much whatever you want. So if you decide, okay, I'm going to fast path composing mail, then maybe in the background, you start to load some of the other stuff that is on your application. But you never want to leave large blank spaces, tons of loading time. One of the things that annoys me about Gmail is that loading bar at the beginning. Because I know it's telling me, I'm not ready for you to do what you came here to do. And I think that goes to the perception of performance more than anything else. That if there is some way to progressively load things so that you don't get those giant blank screens and like long waits with loading, whether it's a spinner or a progress bar, that will make it seem faster. So let's talk a little bit about your talk here. Tongue in cheek, what do you got against JavaScript? But your talk is enough for the JavaScript already. And we almost put that at the context. You're not against JavaScript, obviously, but you want to judiciously use it, if I could say so. Yeah, definitely not against JavaScript. I love JavaScript, it's my favorite language. And it's what I built my career around. So I have no problem with that. The big issue that I'm seeing is that people are using so much of it that they're running into problems they wouldn't otherwise run into. And when I was consulting, I would go into these companies and they would say, help me, our application is slow, what's going on? And I would go in and inevitably I would see, we're talking about like one to two megabytes of JavaScript being loaded into the browser. Well, of course it's slow because you have that much code. So how can we achieve the same things, but with less code? Yeah, how much of that one to two megabytes is actually necessary in being utilized? That would be your experience. A lot of times when I would go in, what I would find is that there would only be about 35 to 40% of that code that would be used by the time the page was completely loaded. So that meant that you were loading in over a meg because it might be used at some point in the future. And I think that we're starting to see that a lot more. People are saying, you know what, computers are faster, browsers are faster. I'm just going to start loading a ton of code and we tend to repeat this pattern over and over again as engineers. Because when I was growing up and I had an Apple IIe, people were very, very careful about how much memory they were using in their programs. But as computers got more powerful, I said, you know what, memory is free, CPU is free, I'm just going to do whatever I want to get the end result. And we always end up hitting this barrier where we run into a performance problem. And the answer a lot of times is like, well, the computer will catch up eventually, we'll just keep what we're doing. And so what I'm trying to focus on is you can actually achieve a lot with a lot less code if you stop and really think about what it is you're trying to accomplish. Okay, so obviously that's what you're going to be talking about, your talk is tomorrow, right? Yeah. Good, so what time is that? Just a little plug here. It's five o'clock. Five o'clock tomorrow, so check that out. Talk about other sort of lessons learned, sort of best practices that you're advising folks, maybe as a former consultant. Once a consultant, always a consultant I save. So things you see that might be useful for some of your colleagues and peers. Yeah, I think one of the biggest things is to make sure that you're taking full advantage of the various layers of a web application. And by various layers, I mean there's JavaScript, obviously, there's CSS, there's HTML, there's the server, and there's the browser. And all of these parts have important jobs to play in the overall lifecycle of your web app. And just like any team, that when you're able to delegate responsibilities efficiently across all of those team members, then everything works better. So I would always leave my clients with a phrase that's when you can do it on the server, do it on the server. When you can do it in HTML, you do it in HTML. When you can do it in CSS, you do it in CSS. And only once you've exhausted all of those other possibilities do you go to JavaScript. And by doing that, you create a nice balanced web app where you don't have to touch JavaScript every time you have to make a change. And that, in turn, helps a lot with the performance strategy. Yeah, so avoiding JavaScript creep and then getting much more efficiency out of your code. What's going on at Box these days that's exciting you? What are you working on that you can talk about that floats your boat? Yeah, I think the most exciting thing about Box is how the company is growing. And one of the problems that I love solving is for scale. And Box is going through that place that I think a lot of companies want to get to that is we've grown from a small company and have started to get larger and larger and larger. And as you do that, it's time to shift the way that you think about solving problems because the way that you deal with 10 customers is not the way that you deal with 100 customers. And so there's a lot of interesting growth that's going on, both technology-wise and organizationally, and the company as a whole, obviously we're a sponsor at Velocity this year which is really exciting for us. And really just getting in and seeing all of the great work that people have done to lay a foundation of a really strong company and helping that organization to take the next step. So how do we eventually end up at the same scale as like a Yahoo or a Google? So talk about your sponsorship here. What's the motivation? What do you guys get out of the sponsorship here? It's a little bit different than a belly to belly exchanging cards type of thing. It's, you know, you're giving back to the community, you're recruiting people. Talk about that a little bit. Yeah, well, I don't think that there's a huge secret to why companies sponsor conferences. We want to let people know that we're a part of this tech community and we're giving back, I'm giving talks here. We've had a lot of people from Box giving talks at like Velocity in Europe. And we feel like we have a lot to offer because we're in a space that's kind of interesting and that I think a lot of people are still unfamiliar with that a lot of companies who usually sponsor large conferences are more consumer focused but there's a really interesting and compelling technical set of challenges when you're dealing with the enterprise and we want to share our experiences, give back and also just interface with everybody else and see, you know, how can we take what we've learned that may apply to what you're doing? How can you explain to us what you've learned? Maybe we can apply that as well. Excellent, all right, Nicholas Sekis, thanks very much for coming on theCUBE. We appreciate it. John, we're going wall-to-wall today. It's tomorrow. Yeah, and tomorrow, this is theCUBE. We'll be right back with our next guest after this short break. This is live coverage of theCUBE here at Velocity Conference in Santa Clara. This is Silicon Angle and Mookie Bond. I'm John Furrier with Dave Vellante. We'll be right back with our next guest after this short break.