Assuming that my page doesn't have SSL. Let's suppose the following steps:
User makes a request to my webpage (let's call it www.mypage.com).
Client-side JS makes a SYMMETRIC KEY.
Client-side JS makes a request to my backend page, asking for the PUBLIC KEY of my server.
Client-side JS encrypts the SYMMETRIC KEY that was generated previously within the obtained PUBLIC KEY.
Client-side JS sends the ENCRYPTED data to the SERVER.
The server decrypts the received data.
The server starts to send/read every following information encrypted within the SYMMETRIC KEY generated in STEP 2.
Client-side JS also starts to send/read every following information encrypted within the SYMMETRIC KEY generated in STEP 2.
According to my knowledge, even if the attacker is listening to every piece of information from steps 1 to 8, they cannot decrypt anything, and the user is safe.
Do you guys agree with me? Am I correct? If yes, can we assume that native SSL in browsers exists because of "poorly written" pages?
TLS is to protect the communication between a client and server against a man in the middle attacker able to intercept and modify the communication. This could be the ISP, this could be the owner of a public WiFi Hotspot, or it could be an attacker in your LAN or WiFi Hotspot which redirects your traffic using ARP or DNS spoofing. Lets's see how this proposed approach works in this case.
Client-side JS makes a SYMMETRIC KEY.
Where does this client side JS comes from in the first place? Hopefully not from the server because there is no guarantee that an attacker has not modified it. But assuming this was transferred to the client with some kind of secure connection ...
Client-side JS makes a request to my backend page, asking for the PUBLIC KEY of my server.
Since this request to the server is not protected against interception and modification a man in the middle attacker can simply replace the public key with its own and send it to the client. Since the client has no kind of validation of the public key (i.e. no authentication of the server) it will accept it.
From then on the client will believe to exchange the symmetric key and encrypted traffic with the server, while actually exchanging it with the attacker. The attacker can decrypt the symmetric key and the traffic and build from this its own connection to the server, this time with the original key from the server.
In summary: you are missing a critical point of TLS - the server authentication. This allows an active man in the middle to easily break the protection.
Note that there are more flaws in your approach, like no forward transparency, no message integrity, no replay protection. But missing server authentication is the most obvious and most critical problem.
If yes, can we assume that native SSL in browsers exists because of "poorly written" pages?
It is built into the browsers since encryption is easy to get wrong, so don't rely on users doing their own. And it is shipped with root CA as trust anchors since encryption with a previously unknown remote party needs some way to validate that the party is actually the intended one (the server authentication you are missing), which is done by checking the server certificate in TLS against the built in trusted root CA.
See also Why shouldn't we roll our own? on why you should not try to invent your own cryptographic protocol but instead rely on established standards.