HTML and Javascript are interpreted on the client side. For login purposes, it is the server side code that is commonly used to verify the credentials - simply because that fact that you are already aware of - with a simple client side implementation, you can see the credentials in source code, server side is also easier to work with, once you understand it, it is more flexible for further development, it is more secure, and it is really used everywhere for this task.
It is a good idea to use PHP, ASP, Ruby (or any other server side language) for this. If you do not want that, you need to make it hard for the user to read the credentials from the source code.
In order to do that, you can use various methods like cryptography or obfuscation. Cryptography is highly recommended over obfuscating as it provably adds more security to your application. Obfuscating basically means that you change the source code in a way that it is hard to read - you add functions that encode strings, so that your "password" can not be spotted on the first sight. However, obfuscation can always be bypassed, and usually quite easily with a good debugging tools.
So, let's go with cryptography. What you are looking for here is using one way hash functions. You have plenty to choose from - MD5, SHA1, SHA256, ... each provides different level of security. SHA256 implementation in Javascript is an example you can use. There are many other libraries and examples for this, so just use Google and find the one that you like.
Now, what to do with it? Say you have sha256() function that accepts a string and returns its hash as a string. For each user and password you have, you precount SHA256 hash of string "user + password".
Say, you want your username to be "Pedro" and password for this account is "MyPassword".
You precount the hash of "PedroMyPassword" - e.g. with with online hashing tool. You can see the its SHA256 hash is
40be6e939eedf018b2b846e027067dcb006585a2155ce324f1f2a6a71d418b21
This hash is what you put into your Javascript code.
When the user enters their user and password, you call your sha256 function on "username + password" and you compare it to your precounted hash.
Note that you have to select really strong password, otherwise certain attacks (such as dictionary attack) would be easy to use to break your hash.
The problem is now, that you did not specify, what you want to do next. For example, you might want to redirect authenticated users to next page, but here you have the same problem again - if you have redirection in Javascript to "secondpage.html" in your code, someone could just skip the authentication and navigate to this second page directly.
What you can do in this case is that you name your second page as
40be6e939eedf018b2b846e027067dcb006585a2155ce324f1f2a6a71d418b21.html
i.e. the hash of your user+pass string. In this variant you do not put the hash in the code at all. The web server will just return error 404 for all users that fail to authenticate. For example, if someone attempts to use "Pedro" with "123456" as password, the SHA256 would be
3bac31720fdd4619ebe2e8865ccc0dc87eb744f3f05f08c628bb9217a77e4517
and if you redirect them to
3bac31720fdd4619ebe2e8865ccc0dc87eb744f3f05f08c628bb9217a77e4517.html
it won't exist, because your second page file is called
40be6e939eedf018b2b846e027067dcb006585a2155ce324f1f2a6a71d418b21.html
You would need to create these second pages for each user/pass combination. You could then put a simple redirection code to the real second page.
But make sure you are using HTTPS protocol, otherwise, the second pages would go through the wire unencrypted ...
This all will work, but still, I highly suggest, you consider the server side way.