Prototype Pollution in JavaScript

Rate this content

In 2018, a new attack vector against JavaScript codebases has been published: Prototype Pollution.
At first glance, it seemed pretty limited in impact: it would basically be a good way to crash some code. However, multiple cases of Remote Code Executions have happened based on this vector.
In this talk, we will clarify what are prototype pollutions, their real impact and of to prevent them from happening in your codebase.

27 min
14 Apr, 2023

AI Generated Video Summary

This Talk discusses prototype production in JavaScript and focuses on the concept of prototype pollution. It explains the impact of prototype pollution and ways to avoid it. The Talk also highlights real-world examples of prototype pollution vulnerabilities in Kibana and MongoDB. It provides recommendations for preventing and mitigating prototype pollution, such as filtering out merge functions and using defensive objects. The Talk concludes with a discussion on tools like Semgrep for static analysis and the importance of sanitization and validation in preventing outside attacks.

1. Introduction

Short description:

We'll talk about prototype production in JavaScript, but before that, let's address something important. The speaker discusses their current situation, being unemployed and working on building a company.

Thanks a lot. So we'll talk about prototype production in JavaScript, but before we do that, let's talk about something very important, me. So the bio is a bit outdated and that's on me. I don't work at Datadog anymore, like since two weeks ago. And I'm working at a company named QueryTails that is not even a company I need to tell the lawyer to incorporate. And it's not even an association because it's basically myself. So if you want to feel sad for me, you have to know that I feel so lonely that I do my stand up meetings with Chad GPT in the morning. And speaking of the logo of the companies that's another AI that designed it. So that's basically me being unemployed on Twitter, French unemployment money, trying to build a company.

2. Understanding Prototype Pollution

Short description:

Let's talk about prototype pollution. First, let's learn what prototypes are. We'll also discuss the impact of prototype pollution and avoiding it in JavaScript. JavaScript is prototype-based and somewhat typed. We have the type of operator to check variable types. Objects in JavaScript have prototypes, and when a method or property is not found on an object, it's looked up on the prototype. We'll recursively check the prototype chain until we find the method or property. If it's nowhere in the prototype chain, it's undefined.

But let's talk about prototype pollution. So first of all, before we pollute prototypes, let's learn what prototypes are. Even if that's a JavaScript conference, it doesn't hurt to go back. Also, you can notice there is no design in my slides whatsoever because designing these slides consisted of removing the Datadog logo and color scheme late yesterday in the plane.

Then we will talk about the impact of prototype pollution and avoiding prototype pollution in JavaScript. And this talk has been designed for twenty five minutes and I only had twenty of them. JavaScript is prototype based and somewhat typed. OK, what do I mean? Let's start with the type part because it's probably the most trolly. Well, you've got the type of operator and you can check the types of variables. So types of true is a boolean, type of null is an object that's called the billion dollar mystic, but that's not the topic of this talk. Type of 10 is number type of 10 n is bigint and so on and so on. We even have the undefined type for stuff that are undefined. JavaScript is so great. And pretty much everything else is an object. So objects are objects. String objects are objects. Regex are objects, null is an object and objects are objects. Obviously again and objects have methods like if you create the object Foo1 and call hasOnProperty on it, it we returned true. And if you create the object Foo1 and check hasOnProperty, hasOnProperty, it will return false because the method hasOnProperty does not belong to the Foo object.

So where does it belong? Let's use the best tool in history of programming, the debugger. And we can check our object and see that the method hasOnProperty exists on something that's called a prototype and the prototype can be accessed from the object directly. So what are prototypes? In JavaScript, objects have prototypes. When a method or property is not found on an object, it's looked up on the prototype. But prototypes are objects. So if a method or property is not found on a prototype, we check it on its prototype. But the prototypes are objects. So if a method or property is not found on the prototype, we can check in the prototype. And that's what we call the prototype chain. It means that we will recursively check the whole prototype chain until we get to null, to find a method or a property. And if it's nowhere in the prototype chain, it's undefined and undefined is not a function.

3. Understanding Prototype Chain

Short description:

The prototype chain forms a tree structure. Objects created with different methods may or may not share prototypes. Item three has a prototype, my proto, while item one and item two have the prototype of class one. The prototype of old style class is still in the chain. The method bar is not available on cl.prototype but is available on old style class.prototype.

So prototype chain, basically, it's a tree. So on the left hand side, I defined a prototype in my proto. I use that to create objects. I defined a class with a constructor, old style class. I give it a prototype directly, and I even define a class with the class keyword. And basically when I create objects on the right hand side with these, they will share prototypes or not.

Okay. Let's go a bit deeper. Item three has a prototype, my proto, because on line eight on the right hand side code, we set objects dot set prototype of on this object. So we have a method to arbitrarily put a prototype on an object, but item one and item two, the prototype of the class one, because we created them with new and called the constructor of the class at the bottom of the left hand side. But since this class extends old style class, well the prototype of old style class define a line eight to 13 on the left hand side is still on the chain. So if I want to check the method, the method bar on item one or item two, it won't be available on cl.prototype but it will be available on old style class.prototype. Okay. Is that clear? I hope. Please don't throw stuff at me. Okay, thanks.

4. Accessing Object Prototypes

Short description:

To access the prototype of an object in JavaScript, there are multiple ways. We can use the Object.getPrototypeOf() method, the __proto__ property, or the constructor.prototype property. It's important to note that there is a single instance of the prototype in the heap.

So how do we access the prototype of an object? Yeah. But the people telling me it was clear, knows everything about prototype. So how do we access the prototype of an object? We have multiple ways. So let's have a class named my class because I'm very original in the way I name my classes and create two items, my item and my item two. If we check, if show prop, which is a method of the class is available on this object, they are not, because has on property on line 13 tell us it's not available on the object directly. But if we do object get prototype of my item, this will return the prototype of the class. And this has the own property show prop, that's what we are on line 14. We can also access a prototype with underscore, underscore, proto underscore, underscore. So if we do my item, underscore, underscore, proto, underscore underscore that has on property show prop, it will return true. And if we console.log my item.constructor.prototype has on property show prop, it will return true too. And what is worth noticing that there is a single instance of this prototype in the heap, meaning my item dot underscore underscore proto underscore underscore, is exactly the same thing as my item two underscore, underscore, proto, underscore, underscore. Pretty sure nobody said prototypes that much in their life in a short amount of time.

5. Prototype Pollution in JavaScript

Short description:

Prototype pollution occurs when an arbitrary payload can overwrite properties or methods on the prototype chain of objects. This can happen when using a merge function. A specific example is shown with the Hook library, where a malicious payload is used to modify the prototype chain. The impact of prototype pollution can be severe, with over 200 disclosed vulnerabilities since 2018, including remote code execution in Kibana and the PaaS server.

So what's a prototype pollution? Well, a prototype pollution happens when an arbitrary payload handled by the JavaScript code base can overwrite properties or method somewhere on the prototype chain of one or multiple objects. This usually happens when we use a merge function and we will see in details why.

So what do I mean? Let's take an example. Let's take the Hook library in version 4.1.2, 4.2.0 and we have something called malicious payload on line two and that's a string that contains underscore underscore proto underscore underscore oops it works, and then we create an object name A and this object has nothing to do with malicious payload. In this world code base, it's never called in the same function as malicious payload. It doesn't know about malicious payload. So we console.log A.oops and it's undefined because oops is not present on the A object. Nor it is present on its prototype chain because it inherits from the default prototype chain of any object in JavaScript. Then we call hug.merge on a brand new object, nothing to see with A and JSON don't pass malicious payload. And after that, when we call A.oops, it will return it works. Because the prototype of all objects, the prototype of objects, the main prototype of the heap of this JavaScript codebase, now has the oops property. How comes? Well, it's because of a recursion.

So this is the merge function that we've seen on line five on the previous slide. And this function is actually performing recursive merge, meaning that if you want to merge two objects, and they have properties that might be in common on their sub objects, it will recursively check for them. But because of __proto__ being an accessible property on most objects, well, the function will say, Oh, I've got something in proto to write on this object and this object has proto. So we'll take the value of the prototype of the object and start writing stuff on that. So what I mean is that through the merge function, because of this recursive call on line 18, we go up the prototype chain and we write, oops. And that worked in lodash too, because I want to terrify everyone. I mean, in older versions of lodash, you've got another payload constructor, prototype, isAdmin. You remember I showed you we can access the prototype of function of an object by going through constructor.prototype. Well, we do exactly the same thing. We have an object B, B.isAdmin is undefined. We use lodash.merge on an object that has nothing to do with B and payload as a second argument. And then B.isAdmin is true. And oh, sorry. And lodash is insanely popular, this slide is not for JavaScript code, it's for security code. You all know that lodash is insanely popular and cool.

So what does the impact of prototype pollution? Because it sounds like a good way to mess with someone's code base, but can it be evil? So since 2018, there have been more than around 200 CVEs, CVEs mean public vulnerabilities disclosed for everyone to know and not every vulnerabilities get a CVE. So that's probably the top of the iceberg. There have been a few remote code execution in Kibana and the PaaS server, and no, I'm not working at Datadog anymore, so I can say what I think about Kibana without looking so well.

6. Prototype Pollution in Kibana and Parse Server

Short description:

KTH University published an interesting paper on prototype pollution in Kibana. The Node.js child processes in Kibana share the parent process environment through a JavaScript object. The Node.option environment variable allows passing command line arguments. The dash e option enables running code passed as a string. Prototype pollution in Kibana allowed writing Node option in the prototype chain. This allowed running arbitrary code on the server and spawning child processes. Dash e is no longer allowed in Node option, but a bypass exists. Kibana has fixed the prototype pollution issue. Parse is a backend project for mobile apps that exposes an API in front of MongoDB.

So I expect some slides about that and KTH University published a very interesting paper on this topic last summer. So the Kibana case CVE-2019-7609, basically it's a very, very fun one. I love it. So Kibana use child processes from Node.js for certain stuff. Like if you want to do some computation in Kibana, it will spawn a child process. And when you spawn a child process from Node.js, it will share the environment from the parent process to the children process through a JavaScript object. You see where this is going? There's an environment variable in Node.js that's named Node.option that you can use to pass common line arguments to the Node binary. So instead of doing Node dash dash something, you can do Node.option, put your dash dash something in it, and then when you start Node it will catch this up. And there is also the dash e or dash dash evil command line option in Node that enables you to run code passed as a string in the command line. So the example here is Node dash e console.log hello that actually starts a Node process and runs console.log hello. Let's prototype pollute this. Well, why do I have, oh yeah. I'm missing something. Okay. I'm missing a slide. Sorry about that. So basically there was a prototype pollution in Kibana and you were able to write Node option in the prototype chain. You know, you would prototype pollute and every JavaScript object in this heap. When you check if Node option is defined, it will respond with, oh yeah, there is a dash e execute by evil record execution, with the string. And that's basically what happened to Kibana. So if you had access to a Kibana server to a Kibana UI, you could run arbitrary code on the server and then spawn another try process with your share arguments on everything you want. So we fixed that. Dash e is not allowed in Node option anymore, but there is a bypass and it's public, but I won't talk to that. And Kibana has fixed the prototype pollution. The original paper is very interesting, very accessible and there is also a talk, certainly on that topic, very, very interesting to watch.

Parse server. So parse, who is familiar with Parse here? It was very, very popular a while ago. It's basically a backend project for mobile applications that expose an API in front of a MongoDB server, being acquired by Facebook, shut down by Facebook, and now there is only an open source version that only Google shut down product people love. And basically that's an API in front of MongoDB. You can store objects.

7. Prototype Pollution in MongoDB

Short description:

You can request object from MongoDB through a wave API. It's vulnerable to prototype pollution before it was fixed. The library used, bsonjs, allows storing functions in MongoDB. By default, functions are not unserialized. However, if the eval function option for the bson library is true, arbitrary functions can be evaluated. This can lead to running arbitrary code when retrieving objects from the database.

You can request object from MongoDB through a wave API. It's vulnerable to prototype pollution before it was fixed of course. And it uses a library that's named bsonjs. So, bson is a format to store objects in MongoDB. It stands for binary JSON or something like that. But, bson allows you to store functions that will be stored in MongoDB and you can unserialize. But by default, they are not unserialized. Because unserializing a function that would come from a database would basically mean, let's do eval on that string that comes from the database I have no idea about, and you don't want that to be a default. But if the option eval function on the object used an option for the bson library is true, well, you will be evaluating those arbitrary functions. And because Parse allows you to write pretty much anything you want in your database from the network, because it's Parse, you could actually run arbitrary code when the object is retrieved, which is, oh my god, that's because they check the diversion hack.

8. Preventing Prototype Pollution

Short description:

To prevent prototype pollution, filter out merge functions and specifically remove underscore, underscore, proto, underscore, underscore. Lodash has fixed all instances of prototype pollution. When using as-owned property, ensure it exists on the object and not its prototype chain. Building defensive objects using Object.create or Object.createNull can prevent prototype pollution. Sanitization and data validation are crucial for preventing outside attacks. Consider using libraries like joy for data sanitization when building a Node.js web server. Node.js has an option to disable proto, underscore, underscore, proto, underscore, underscore, but be cautious as it may break some code.

How to prevent prototype pollution because I'm a responsible person, I don't want you to feel scared and say, you know, let's use a language without prototypes like Python. How to prevent? Well, let's filter out, you know, merge functions. You see, for instance online nine here, line nine, nine, three, or online four here, that we filter out, underscore, underscore, proto, underscore, underscore. And that's what we've been fixing a lot of libraries. Lodash has been adding more prototype pollution than any other library I know, and they've been all fixed one by one. If you find a new one, feel free to responsibly disclose it to their maintainer, whatever libraries it is.

Sometimes, you will know that your code path is critical and you want to make sure that you're using as-owned property. Well, well, as-owned property can be tampered with with third-party attacks, but that's something else. So make sure that if you expect a property to exist on an object, you make sure that it exists on the object and not on its prototype chain. Also, this one I like. It's what I call building defensive object. I don't know if that's the academic term, but you can use Object.create and that will create a new object with its arguments as prototype. Well, null is an object. So you can do Object.createNull. These objects won't have all the methods you expect them to have as-owned property, as-owned symbols, get-owned-property descriptors, but this object will be safe from prototype pollutions because it doesn't have any prototype.

Sanitization, make sure that stuff that gets in your process from the outside are safe. Do data validation. I love the joy library because I'm a happy, happy thin fat boy, but there are a lot of amazing libraries to do data sanitization. Use them. They are very cool. And anyway, you should use them if you're building a web server with Node.js. As mentioned that will also probably remove your surface of attack to no secret injection. So go for it.

Conclusions. Oh my god, I'm on time. What's now? Monitor incoming objects Node.js has an option to disable proto, underscore, underscore, proto, underscore, underscore. It might break some code. So be warned that it might break some code because the Internet but you can use it. And for sanitization and prototype less object. Oh, you remember why I told you should use Python? That was a joke in January.

9. Mitigating Prototype Pollution

Short description:

Someone published a paper about class pollution in Python. There is no proof of actual use in the wild for malicious attacks, but it highlights the vulnerability. It's important to check where your objects come from in your codebase, especially for web applications that accept objects from the outside. Be cautious of third-party attacks from NPM modules and inputs from the network. Sanitize and validate the objects that enter your app to prevent injections and ensure they match your expectations. Use tools like Sneak Audit and NPM Audit to check for known vulnerabilities in your codebase.

Someone published a paper. There is no proof of actual use in the wild for malicious attacks, but there have been a paper about class pollution saying that oh basically Python is vulnerable to that too. So there's nowhere safe.

Some links. The slides will be on Twitter. Please shout on Twitter if you want the slides. So let's stay in touch. You can find my Twitter with this short URL.

I hope you enjoyed this presentation and you have questions that I can answer. Thanks so much for being an amazing group. We will come to this question in due course. There was a lot of suggestions there on how you can mitigate the risks brought about by prototype pollution. If our audience were to go home and go to their code bases that they're currently working on and with the concerns that they may now have, what would be the first thing that you encourage people to do? Maybe it's a more simple low lift action or starting off a more significant piece of work.

That's a very good question. I think the first thing to do after being at a conference talk about security in Node altogether, when you come back is check where your objects come from, and that's true for mitigating prototype pollution, but also all sort of injections. So when I mean that, I mean, at some point, if you have a web application, it might accept objects from the outside. Can be the query strings, can be the body. At some point, there is a library in your code base that will pass a text HTTP request and return a JavaScript object. That's probably the main source of malicious inputs. Because your application, it can be vulnerable to third-party attacks from your NPM modules, all for the inputs coming from the network. And me, I prefer to think about the things coming from the network, talk about, talk to ZB If you are interested in the other threat model, the part of the threat model. So check the object that comes into your app and check what you are doing with them. Are you sanitizing them? Do you know their shape? Is there an error in your code when they don't like, when they don't look what you expect? That means method that, properties that you are expecting of the object, but also, are you sure that the object doesn't have properties you don't expect? So objects that get into your app, you must know what they look like. And that will, that will be the first way to know that nobody is injecting some kind of underscore, underscore, proto or constructor elements on your objects. Cool.

Thank you so much. So some questions from the audience, is there an easy way, I think you touched on this, but I'll ask the question explicitly regardless. Is there an easy way to check if my service is vulnerable to this attack, someone who uses a lot of third-party NPM modules? Sneak Audit, NPM Audit, you will already know the vulnerable methods, if they are known. Check if you're using merge methods in your own code, but yeah, basically making sure you don't have known vulnerability in your codebase is the first step. Ideally, frameworks should be able to handle these kinds of things for us.


Questions and Answers

Short description:

Are there equivalents to Express or Fastify that prevent prototype pollution? I'm not sure, but it's worth checking the documentation. The -e argument in node options bypass allows passing a JavaScript code string instead of a file. Object.assign may not create polluted prototypes, but further research is needed. Other ways of achieving RCE with prototype pollution depend on the application's string evaluation capabilities. Consider using maps instead of objects to avoid pollution, but ensure there is no intrinsic pollution. It's unclear if merging objects with a native spread operator is safe from pollution. It's important to explore different solutions and not assume vulnerability. ES lint rules detecting these problems may require taint tracking.

Are they? Is there something like Express or Fastify or equivalents that prevents prototype pollution? As far as I know now, but I'm not up to date on Fastify documentation, Express documentation, I'm up to date because it hasn't changed in five or six years, but I don't think so. That's a very good point, I guess Matteo will say PRs are welcome, so feel free to PR Fastify.

The next question is something you mentioned in your talk, but it has had a couple of thumbs up. So I want to ask it regardless. What is the "-e argument in the node options bypass? Okay, so "-e is short for "-eval and basically it gives you an opportunity to pass a string as argument instead of a file and run this string as if it was a JavaScript file. So instead of doing node index.js, you do node "-e and you put a string with your whole JavaScript code and that that will execute it. Great. Thank you.

Does object.assign also create polluted prototypes? That's a good question. I want to say no, but I'm not sure of it. So that's your homework for tonight. I don't think so, but was checking. Didn't think you were coming to no congress for that homework. Are there other ways of doing RCE with prototype pollution without node options like in the Cabana example? Well, there was the bison example with a function being in serialized. So I guess so in a way, that really depends on the application you are attacking, does this application as string evaluation at some point whether it's through environment variables, through eval, through with VM the transcode, in that case, yes, but it's very business logic dependent. Thank you. Got a few more, you want to get through. Should we, based on your talk, should we therefore be using maps more and instead of objects to avoid these problems? I mean, yes. Yes. I mean, just make sure that you're, if you're very very cautious about that, you need to ensure that there is no intrinsic pollution, meaning that someone overrides the map based methods, they can't do that as far as I know with prototype pollution, but they can do that with a malicious third party. The Node.js code, code base is actually very defensive against that, so you can check. But yeah, maps is probably one of the smartest thing you can do in your web application as far as I'm concerned, I love maps. If you've been to James' talk about asynchronous storage, the first version I proposed of asynchronous storage would force you to use a map as the store, so as a map lover, I would say yes, but I'm biased. Just a tad. What if I merge an object with a native spread operator instead of the old version, an old version of lodash? I think you're safe from prototype pollution, but it's like object data assigned, I never tried it, so I can't be assertive on that. I think with a lot of these questions it is probably the case of like as you're trying to solve for this risk that you are trying all the solutions and seeing what the outcome is, right? Also, I kind of hope if these ways were vulnerable to prototype pollution, we would vastly know it as a community, so that's why I tend to think we are safe, but as a security person, I don't want to handle things. And you don't want to assume either. Are there or could there be some kind of ES lint rules that detect these problems? Good question. There could be a need. It's hard because it needs a bit of taint tracking.

Semgrep and Merging Objects

Short description:

Semgrep is a powerful static analysis code that can find vulnerabilities by running part of your code in a VM. It's open source and designed to check if you're merging based on incoming objects.

There could be at least a semgrep rule that will check that you're merging based on incoming objects. So semgrep for those who are not familiar is a static analysis code. It's open source. It's written in Okeanos, built on the west coast, it's really really cool and it's designed to find vulnerabilities. But it's a bit smart. It's more powerful than most linting tools because it has some kind of symbolic execution engine and can basically run part of your code in a VM. I mean executes part of your code and decide if it's vulnerable. So I'm not sure about linter but I'm pretty sure about semgrep. Cool. Awesome.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.