If you're on a halfway decent server - one that can respond to clients in your service area quickly - it's unlikely to matter.

The biggest issue with including many separate files is that, if your server uses HTTP/1.1, clients will usually only be able to request a small handful of resources at a time (10 or less). If you have a whole bunch of resources that the client needs to download for the app to function, and the ping between the client and your server isn't great, this could increase the time it takes for your site to initially appear functional. But for only 10 script files, it's probably not an issue. (Look at many of the large sites of today, and you'll see that quite a few of them load a huge number of resources.)

If your server uses HTTP/2, clients will be able to download all files requested at once, without a limit on the number (except for bandwidth), so in that situation, using many different files is less likely to create issues.

Still, for larger applications, it could be a good idea to bundle up your script into a single file for production. There are many options out there, and they have a bunch of benefits - they're often considered essential for a modern application.

Ideally it is all in one file. On your development computer you will probably have several js files, especially as you begin including various js packages or frameworks to your web application (website). On your development machine, you can manually use a tool like grunt to automate the creation of that single js file from several different js files, or you can automate the build process and other pre-deployment tasks using a CI/CD pipeline.