Nodejs and performances: a quick chat with Daniel Khan
While waiting for Codemotion Rome 2016 to kick in, we will continue our chat with our speakers. Today is Daniel Khan’s turn.
Daniel is a as technology strategist at Dynatrace. He started his career in front of his father’s Sinclair ZX Spectrum, then the “Word Wide Web” crossed his path some years later and he built an ugly personal website on GeoCities. Nevertheless he became a go-to-person for websites of all kinds, found out that he needs Perl to send a form by email and MySQL to store things. The rest is history. Perl became PHP, PHP became Nodejs and trial and error became craftsmanship. He is really interested about software performance, he also share his thoughts and experience about it on this blog
Hi Daniel, could you give us a quick introduction of your talk?
Hi! Sure – In my talk I’ll show some of the most common performance problems that can occur in Node.js and I’ll show ways how to track them down. Besides that it’s really important to me that attendees understand what’s going on under the hood. What does the garbage collector do? What does the event loop do and what happens when we do CPU heavy operations in Node.js? So I will cover that as well and I hope that newcomers and seasoned developers will both get something out of my talk.
How and why did you get so passionate about javascript and nodejs?
I started with web development in 1999. I really hated JavaScript these days. Looking back I have to confess that not the language itself was to blame but the flaky and inconsistent browser support. Over the years I’ve seen so many technologies come and go and I tried many of them. I’ve tried WebForms and Java Server Pages, I’ve done some Rails as well and I always came back to PHP because – to me – it provided the fastest way to get my jobs done. I always avoided using overengineered frameworks as well – it makes me nervous when I don’t know what my code is in really doing.
While working for a startup I had the chance to start a project from scratch and choose the technologies freely (great!!) and I ended up with Node.js for the frontend and Scala Play for the backend. I instantly fell in love with Node as it was so plain simple and easy to grasp after I understood the asynchronous / callback based approach it has. It’s whole module infrastructure is based on small interchangeable units that keep my projects orthogonal. There is no hidden magic. It feels like craftsmanship and not like being the user of a framework.
Long story short: After all those years Node.js was the first platform that supported my way of thinking and it still is. By the way: still I see the need for static typed languages when it comes to business logic – Scala and its Play framework was a really good fit for that and it plays nicely with Node.
From your talk and your blog posts it seems you really care about digging deep into performance issues with Node.js, how did all this start?
This really started with my work as Technology Strategist at Dynatrace. Before that I fixed performance problems as they occurred but didn’t care too much how continuous performance monitoring worked. In my job I really have to find ways to look under the hood of Node.js and analyze what it is doing. Is the memory consumption still in its expected boundaries or is maybe the CPU overloaded, are there third party API’s or database calls that are slow and causing lags that affect users? Digging into these topics really helped me to understand the inner workings of Node.js and I’m happy to share my findings.
For developers who are not used to tools that tackle performance issues, where should they start to get a proper understanding?
They should attend my talk 
Javascript is the most used language in the world, at the moment, and not just on the client side. Where do you see the language in 5 years?
Honestly I hope that it won’t evolve too much. Why fix something that isn’t broken? I even doubt that some ES6 language features were such a good idea. Take the introduction of ‘classes’ which – under the hood – boil down to the “old” prototype based syntax – so why should we have two ways of expressing the same thing? I’d really prefer to keep things simple.
Looking at JavaScript from an market adoption angle I think it will stay for a long time. Frameworks and platforms may change but JavaScript is obviously here to stay and investing into really learning the language will pay off big time.
We are expecting to draw about 2000 people at Codemotion Rome, what’s your feeling about it?
That is huge! I’m really excited about that and I hope that many of them will attend my talk
Is there any book related to your passion that you would suggest?
The “You don’t know JS” series by Kyle Simpson, because it really covers the language with all it’s features and possible pitfalls. It’s even freely available on github. I bought the books though.
What’s your current music album on repeat?
Blackstar by David Bowie (RIP)
If you could improve one thing in tech conferences, what would it be?
There are so many conference formats that there is almost no catchall answer to that but if I could improve one thing I’d offer more beginner-level talks for any given technology. We can not assume that everyone knows JavaScript, Java, Go or you name it. At any given time there are lots of developers or even total newcomers we should try to onboard. After my talks attendees often approach me to tell me that they liked it though they are just starting with Node.
I’m always proposing introductory talks to conferences but almost every time the more advanced topics get selected.
I won’t give up and I’m already working on a talk on “How to become a web developer”
Thanks for the insights Daniel, see you at Codemotion Rome 2016!
Back to news list
