I used to code in VB.NET at College (UK College) where there were two ways to encapsulate code: via a method and a function. A method would just execute some code; a function on the other hand had the advantage of returning a value as well.
Now I'm coding using a procedural style for a course in Javascript.
My question is, are functions in Procedural languages capable of returning values? Or is this just an Object-Oriented feature? Or is this a universal feature among all languages?
Being able to return value from a call is entirely orthogonal to procedural/functional/OOP/what have you.
Javascript does support returning values from calls, since it's a pretty functional language, and functions that don't return values would be rather embarassing. Most other languages allow you to do the same thing. In fact, Javascript is a multi-paradigm language - and you can see it being used in many different roles, down to querying. It allows you to mix and match styles quite well, or just pick your favourite approach and stick to it.
There's no such thing as "procedural style". Just like there's no "functional style" or "OOP style" or "relational style". Those are just extremely wide labels with no objective background. Think about what you need to do, and find a way to do it. The only case in which labels like these matter is when somebody wants to force a particular style on you - in that case, ask what they mean exactly - we can't help you, it's in their head.
For example, procedural code used to mean "no structured constructs". No functions, procedures, not even ifs and loops. Today, most people actually use the term "procedural" to mean what used to be "structural programming" - procedures and functions, with "high level" constructs like structured branches and loops, and tons of global variables (though hopefully, you no longer pass arguments and return values through global variables - YMMV :)).
"Object-oriented programming" used to mean "sending messages back and forth" - the seminal OOP paper didn't even have return values, you were just supposed to listen for a "response message" if you needed a response. After all, the target object might answer much later or never at all (say, when it gets an I/O response). It definitely didn't have any form of static typing (and one could argue it didn't really have a concept of types at all) - instead, you had objects that listened for messages. When a message came, the object figured out what to do with it - all objects were dynamic. The only public interfaces were those messages - everything else was just internal details of the object. Unsurprisingly, distributed systems are rekindling the popularity of approaches like this, since the model is inherently asynchronous and rather loosely coupled.
Javascript doesn't support classes, sure. But classes are entirely orthogonal to OOP - they're just one way of implementing typing and (more importantly) subtyping in a language. Prototypes are no better or worse than classes; functions are no better or worse than classes. All three are perfectly valid approaches to OOP (and programming in general), as is ignoring typing entirely, which Javascript mostly does. While you do have ways of tracking types of objects, ultimately only the actual instance of the object really matters.
Those terms are mostly useless, used most often for the derision of a style you don't like :) In the best case, they represent some past time where a given interpretation of the term was popular in some circles - make sure to communicate what is actually meant by a given term. "Procedural" might mean "don't use objects", "don't use functions", "use global variables for everything", any number of things. We can't tell what your supervisor/teacher/boss considers "procedural" - only he can.
