Where to Begin

JavaScript
1

I know next to nothing about JavaScript. I’ve done a couple of very basic tutorials that allow me to identify variables, constants, and functions, but I cannot parse statements and understand them yet. And that’s just the language itself. Then, there are front-end and back-end scripts (both in js).

Frontend scripts are either written directly in one’s html or are linked to where they are kept within the collection of html / css / and javascript files that compose one’s website. (NOTE: I plan to stick with .js for both frontend and backend code to avoid having to involve myself in PHP.) Frontend scripts are exposed to DevTools and must be kept free of sensitive information.

Backend scripts, OTOH, can contain sensitive information (like MySQL login credentials, etc.) and must not be exposed to DevTools. This means that they must be kept separate from html, css, and frontend scripts which are at the root level for my website. Backend scripts must not be included at the root level.

How do I distinguish between frontend and backend scripts? Where do I store backend scripts? When I deploy my code from the DEV environment (where I write and change code) to my localhost environment (where I test code) and thence to where I host my website (https://url), what files do I have to include? For example, I can use my FTP client (Filezilla) to upload all the files I have in my top level folder for my website. (By that I mean that I have a directory tree that has folders for html, css, images, styles, and scripts that contain all the files that allow me to display the website, but not process any user input. I can point Filezilla to that folder and it will upload all the files needed.)

There’s also the run-time environment that has to be available to run JavaScript. I know nothing meaningful about this subject. I’ve learned that I need a .env file that contains information that allows access to MySQL when javascript runs and needs to read or write a data table.

As you can tell by my questions that I need to learn a great deal more about javascript. My order of attack is to try to understand the run-time environment as a prerequisite to writing backend code.

So, am I right to try to get a handle on the environment first? If not, why not?

Finally, what sources do you recommend for learning about the run-time environment for .js? The books I have focus almost exclusively on coding in .js with little attention given to teaching about the environment.

TIA

1 Like
3

Disclaimer: I do not know what I am talking about, but I have a clue.

Backend for an interpreted language needs a “server engine” in order to “run the javascript”. The most common is Node.js as a “framework”.

Avoiding PHP, makes life a bit harder IMO. You need to find a “host” that you can run Node.js.

Almost all web hosting have support for PHP. If you use Node (or other framework), you must search for a host that can manage Node. Or even better deploy an own VPS where you have full root access. But then you have to learn a LOT more. VPS is the best “host”, but the greatest challenge. If you want to reduce the challenges, stick to PHP (IMO)

Basically all files that you serve to the localhost.

Do a simple “Hello World” site and try to grasp the “hosting” part first…

Sitepoint has some resources about this. And Freecodecamp. And do not forget the W3school. Learning by doing is my way to learn.

I have close to none experience of PHP and Node, but VPS and databases I manage daily. And I have worked with other frameworks (Angular - Typescript) and other interpreted languages for years. Hence I chose a compiled language instead, based on this experience.

3 Likes
4

You’re making me rethink my choice of node.js over PHP.

My web host does support node.js; so that is not going to be a deal breaker. I do not yet have any backend .js written; so now is the time to make a final decision.

What are the pros and cons of each (node.js and php) other than support for node.js?

5

There was a similar discussion here.

https://www.sitepoint.com/community/t/have-you-ever-chosen-node-js-over-php-and-if-so-why/479628/12

I wouldn’t call NodeJs a framework but a run time environment. Express is a webframework.

If you want to deal with Javascript in the front and backend, then NodeJs is a good choice. That is a Pro.

2 Likes
6

So… to hit the wider points first;

The question you need to ask is “Who needs to execute this script?”
The Front End is the Browser. The End User. You have no final control over the front end; the user can see, and override, anything in the front end, because its on their computer.
The Back End is the Server. The secure space that the browser only gets to see the output from.

If I want a system to pull a record out of the database, I dont want thousands of users around the world accessing my database at a programmatic level. So i put a backend script in place, to handle the user saying “I want to see stuff about Metalwork from the 1840s”, and take that and turn around and go to the database, get the records about Metalwork from the 1840s, and hand them to the user.

In metaphorical terms, the database is a bank vault. The end user (or more precisely, the end user’s browser) is a customer walking into the branch; and your script is the teller. The customer isnt allowed to walk into the vault, but the teller can talk to the customer, verify they are who they say they are, and retrieve their belongings from the vault.

The bank can trust the teller, because they are part of the bank, and the customer cant lean over their desk and push a button that says “I am Joe Smith”. Only the teller can do that.

1 Like
7

Thanks, Zensei.

That link helped me. I also checked with my webhost and was told that they support node.js. I’m not well enough educated to know what that means, exactly. It might mean, for example, that I can install and run node.js there or it might mean that they have a node.js run-time environment that my backend code will run in by just uploading it.

So much to learn. So little time.

8

If backend (node.js) files should never be in the website’s root, shouldn’t there be a separate folder that contains all the backend scripts? If so, don’t they also have to deploy to localhost then to webhost?

I’m unclear on how to handle the files that contain backend scripts (and anything else that shouldn’t be exposed to the user on the frontend). At this point I have 2 folders: appsjs (where my backend scripts reside) and a folder named the same as my website (where all my html, css, images, and frontend scripts reside). My deployment goes from the DEV environment where I work on individual components, to localhost where I test and finally to webhost when I think they are ready.

I have a batch file that handles the deployment from the DEV environment to the Xampp environment. This batch file copies the folders and files to the localhost then write protects the files after deploying them which prevents me tweaking things there and ultimately losing those tweaks. My setup enforces a rule that says changes can only be made in the DEV enviroment because I have another batch file that moves the requisite files from localhost to a staging folder from which I FTP files to my web host.

That means that my Dev-to-Localhost batch file has to copy 2 folders that contain all the files keeping the backend .js files separate from the frontend .js files in 2 different folders. I’m yet to learn how to upload the contents of the appsjs folder to my webhost. If you have advice, please . . . I’m listening. When I think I have it clear in my mind, I’ll consult with my webhosting service to be sure that I’m sending the stuff that should run in node.js to them correctly.

Tell me where I’m going astray, please. I’m here to learn.

9

As I said, how Node work may other answer. But a general answer how I do it today in Debian VPS:

I create a directory in /home directory that contains both client and server stuff. I find it conveniently to use this existing /home folder rather than bury it down deeper in the hierarchy.

/home/myweb/assets (client stuff)
/home/myweb/server.js etc (server stuff outside the assets folder)

The client files – css, js, img, fonts, html, misc (favicon.ico etc) – I put into the “assets” folder.

If you use a VPS, you have to tell Nginx (Apache etc) the path or port to your site.

So my advice is still: Start with a simple hello world! to understand the basic, before you upload your entire site.

1 Like
11

The backend and frontend execute in different computers. When a HTML was first designed, when a page is browsed to, the request goes to the server and the server reads the HTML file and returns it to the client. There was no processing; no backend. Well, HTML forms did allow processing but I am over-simplifying things. HTML forms are the basic method used by backend processing but that is making things too complicated. Now what happens is that when a request is made for a page that specifies backend processing then the processing is done in the server (usually not the client’s computer) and the result is returned to the client. Yes you upload both frontend and backend to the host but the execution of the backend is done in the host. That is why the backend can and should have the sensitive information. The frontend executes in the environment that requested the page, usually a totally separate computer in a different geographic location.

JavaScript is a standard for all browsers. All browsers have a JavaScript run-time environment. Therefore there is no discussion of a JavaScript run-time environment; it just exists. I am not familiar with Node.js beyond fundamental concepts. I think however it would help for you to be more specific about what you mean by JavaScript run-time environment.

1 Like
12

I think however it would help for you to be more specific about what you mean by JavaScript run-time environment.

I read that nodejs was invented ( by Rahm?) to allow javascript to have a run-time environment. What I read said (or the way I remember it) that a browser, being a client side (fronend) app, is essentially the run-time enviromment for HTML/CSS/javascript and even PHP. But PHP was primarily a server side language and before nodejs, javascript could not run on the server side (backend). Nodejs runs on the server side (backend) and can process javascript there, ergo, a server side run-time environment for javascript.

That should confuse everyone as much as I am :nerd_face:.

13

cough now. [/showmyage]

1 Like
14

This may explain.

Essentially it says you can have a runtime environment at the server side and another separate one on the client side.

To be clear, PHP is entirely server side, it can’t execute on the client side. The client only sees PHP’s end result.

1 Like
15

I don’t like the idea to put server stuff files in the home directory which is accessible from outside. In the home directory I would only store files which are allowed to be read by everyone. Even if you try to secure other files, nothing is 100% secure and you can easily avoid it by storing server site files in other directories.

3 Likes
16

Thanks for the hint. Now I embed all files into the executable. So I imagine the compiled executable is at least harder to hack. But I should consider another location in the future…

1 Like
17

Working in PHP, the only server side code in the public root directory is a single include which makes up the index.php file.


<?php require_once "../private/entry.php"; ?>

That’s all. The entry file has in turn includes for all the config and routing. Everything server side is in the inaccessible private directory except that one include.

I have not tried Node yet, but assume you can do similar to keep server side stuff out of reach.

1 Like
18

“To be clear, PHP is entirely server side, it can’t execute on the client side. The client only sees PHP’s end result.”

If PHP is exclusively client side, why then do I have a PHP file for a form? Does that mean that the server must ‘serve’ that form to the client side before it can be seen? The form started life as an HTML file; but working with AI, it was turned into a PHP file to accommodate some issues with editing a multi-line input form?

1 Like
19

In Node/Express you have to tell the server which directory is public (Line 12). There you’ll put your client side javascript, css, images, etc.

image
image2034×1136 302 KB

20

Please read carefully. I said PHP is entirely server side. It is not client side at all.

This means that all the processing is done on the server, once finished, the end result of that processing is served to the client.

So in the case of a form, the user fills and submits the form in the client browser. This sends a request to the form’s processing script on the server (determined by the action attribute). The script on the server processes the form data. Once done, it will serve a result to the client.

A form can in fact be pure HTML, it does not need any back-end for the form itself. But you would typically use server side for validation and processing, particularly where security or data integrity is a concern.

Forms may be processed by js on the client side, but it will therefore be prone to tampering, so not recommended for anything important.

1 Like
21

You would need to post your code for us to know if/why your form is in a .php file.

Here’s a fun fact. If the contents in the .php file is all html markup, with no <?php ?> tags, it is still parsed, tokenized, and interpreted by the php language engine on the server when it is requested. The in-line html markup is tokenized to a php T_INLINE_HTML token, with the token value being the literal in-line html markup. When this now tokenized code is interpreted by the php language engine, the token value (in-line html markup) is output, by php, exactly as is.

22

My apologies for being careless, Sam.

I meant, of course, to say … “If PHP is exclusively server side…”

My form was originally written as HTML. The HTML is now wrapped in PHP. The file now has a .php extension. It begins with ```<?php```and ends with```?>``` Does that mean that the browser must (somehow) invoke the server to show this form to the user regardless of whether or not the user provides data on the form? The file is invoked from a menu line href. How does this differ if the file had remained .html? I understand (I think) that the browser (the frontend) is simply parsing the address bar (similar to a terminal command line?) and responding to user input and files served by the host (web or local) and that processing content on the form doesn’t take place - in the backend - until the submit button is clicked.

I’m still learning a lot . . . daily. So, some relatively obvious things to you might not be obvious to me. For example, it just occurred to me that I might not understand the steps when a browser receives a URL and processes it:
1- browser parses URL entered into address bar
2- browser routes to the domain then reads the index.html file (by default, presumably) and no other files (point being that other HTML files remain on the webhost’s server until invoked by a user action)
3- index.html renders a page which might or might not give options to the user. In my case the index.html has a navbar as well as photo content with captions.
4- user chooses a menu line (the one that links to my form with the .php extension) then the browser parses the code in the navbar to produce the form

Does that reflect anything close to what actually takes place? Of course, I refer only to application processing not under-the-covers OS and TCP/IP and other environmental processing.

Please correct any mistakes or errors in my understanding,