A majority of front-end developers deal with this buzzword all the time: V8. A big part of its popularity is due to the fact that it led JavaScript to a new level of performance. Yes, V8 is very fast. But, how does it perform its magic and why is it so responsive? The official docs state that “V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and Node.js, among others”.
When you’re building a website that needs to be updated in real-time, your first thought is probably to add WebSockets to your application. However Websockets is a low-level protocol and to use it, you’ll need to add another layer on top to manage the information you want to get. This is where MQTT is handy, as it’s a higher-level protocol that simplifies working with data streams.
In today’s post, we’re going to demystify how the number of JavaScript dependencies grows while we’re working on a relatively simple project. Should you be worried about the number of dependencies? Keep in mind that this blog post is related to the Ride Down The JavaScript Dependency Hell blog post that was released a while back. We’ll show a “real-world” example of how a project’s dependencies can grow from zero to 13K.
We’re happy to announce that the latest npm package for error tracking of your front-end with AppSignal has just been released. For those of you who aren’t really familiar with our error tracking service, we suggest you to take a deeper look into our docs. This was one of the bigger releases, and it includes many improvements and bug fixes. Here’s what we’ve done.
Every JavaScript project starts ambitiously, trying not to use too many NPM packages along the way. Even with a lot of effort on our side, packages eventually start piling up. package.json gets more lines over time, and package-lock.json makes pull requests look scary with the number of additions or deletions when dependencies are added. “This is fine” — the team lead says, as other team members nod in agreement. What else are you supposed to do?
Being a UI developer, I’ve learned one thing: It doesn’t matter how carefully you write your code. Suppose you’ve double-checked that you defined and called all functions the right way or followed all the best practices. Even then you’ll see that a tiny variable can sneak behind and create an error. Now, suppose you find out that for some unknown reason a form validation or submit button isn’t working.
Finding slow JavaScript code can be a tricky problem to solve. Small code changes can have a big impact on the performance of your code. Fortunately, many different approaches can help you nail down the exact source of the problem. In this post, you’ll learn about three methods that’ll bring you the results you’re seeking. You can trust manual code inspection, but that has its disadvantages.
My computer programming teacher had always told me that 10% of our time is spent developing 90% of our application, and the other 90% of our time finishing the last 10% of our project. Even with a good project plan and a concept that makes logical sense, most of our time will be consumed with fixing errors. Moreover, with JavaScript, our application can run without obvious errors preventing it from being run, so we have to employ several techniques to make sure everything is running smoothly.
Breadcrumbs can help you debug client-side JavaScript applications, and are available to all Honeybadger customers as of today. One of the things that makes fixing JavaScript errors so difficult is that everything happens on the client-side. When an obscure error happens in a callback, you often lack the context to reproduce it. If the error is critical, you may even resort to deploying debug code to get more information about the events leading up to it.
