It does safeguard against changes. const is slightly different from constants in some other languages so if you have used something similar before then it might be more limited than it is in javascript. The basic rule with const in javascript is that you can only assign/bind to it one time and that time must be when it is being defined.
const hello = "world"; // <-- this is fine
hello = "void"; // <-- this throws an error because hello already has a value
const goodbye; // <-- throws an error because it must have an initial value
const name = prompt("What is your name?"); // <-- this is also fine, you don't have to know the value ahead of time but you can only set it once
When you use const you do get the safeguard of not being able to make the mistake of changing something that should never change, but you also communicate the intent that something should never change. Because you have both the intent and the safeguard the reader (which could be you later) has more information to help understand the code. As I previously mentioned the fact it doesn’t change reduces the need to keep track of it, but it also means that if the reader needs to check what value it has then there is only one place they have to look because after that it can never be set again. It is common in modern javascript to make really heavy use of const especially people who use React.
Yeah you are on track with that. If you haven’t gotten into scopes properly yet then don’t get ahead of yourself and worry too much about them yet, you can pick up what I was saying when you get there and hopefully it will help you make better use of them as you go forward.
var is pretty annoying in many ways, I mentioned it only because you might see it “in the wild” and due to its confusing properties people do use quite a different style to avoid some of the pitfalls of those. Not something to worry about now, only if you are looking at code and you see it then the code is very likely to be structured with all the variables for each function defined together.
It may or may not be good advice, some languages (or in the case of var language features) work quite differently and there may be good reasons to do this kind of thing. In general it used to be a very popular habit that has somewhat faded in favour of defining things close to where they are used but it does depend on how the language works. Most of the popular languages (i.e. ones you will find in the majority of job listings) have quite a bit of similarity and most of them will favour the style of defining things where they are used with ideally the smallest scope possible.
When I was first learning I also found the way for loops work to be really awkward. I always preferred to use while loops as like you they just made more sense to me. They are both equivalent to each other in this case and you can make a for loop by rearranging your while loop but it might feel a bit weird. Practise is important, you need to get used to them especially to make it easier to work with others (where using the more appropriate loop for the task is important) or read other peoples code more comfortably (where they will likely use for loops quite a lot, sometimes some pretty gnarly ones). Like I said before, take some time to work with them but also don’t bring yourself to a complete halt in order to only think about for loops just continue on slightly slower and spend a little time every day or two getting better at them. You can write while loops at the moment if you need to you just can’t ignore for loops forever.
If you are stuck / continue to be stuck, feel free to bring your code sample here and ask why you are getting an error (ideally if you say what the error is that is helpful too).
The brackets need to be balanced (matching number of opens/closes) and most of the time that there is a brackets problem then it is because there is one missing somewhere. It is also sometimes the case that an error can say that a bracket is expected when the problem is not the bracket itself but in fact an error before it has caused the interpreter to become confused about where the bracket should be. Again if you are still having problems, bring an example and we can try to work out what is going on.
If it were designed differently then it could look like that. One of the design goals was to make it have a similar syntax to the C family of languages, C/C++/C#/Java/Go and a bunch of others all have very similar syntax and it is very popular. In this style of syntax blocks are used to group together a collection of statements and expressions. The block starts with the opening { and ends with the closing }, in the block is a collection of related instructions. Blocks can be used in many places and work the same way everywhere they are used, they are used in if to define the chunk of code that should run with the condition is met, in loops to define the chunk of code that should happen on each iteration of the loop, in functions to group the chunk of code that is part of the function and in any other case where some part of the code needs to be wrapped in a boundary. If the design style was like your version then it wouldn’t work the same way all the time, it might need different constructs for each of the cases because for example a loop cannot have a else if randomly shoved into the middle of it. The structure being used here is something like this:
if ([condition])
[block of code to execute when condition true]
else if ([other condition])
[block of code to execute when other condition true]
else
[block of code to execute when everything else is false]
while([condition])
[block of code to execute when condition true]
for([initialisation]; [condition]; [increment])
[block of code to execute when condition is true]
function [name] ([parameters])
[block of code to execute when called]