I am not an engineer
Must read:Is there a real future in data analysis for self-learners without a math degree?

What the heck is Angular 4?

Do you ask yourself which language to learn? When I was wondering about this question, I was told that the starting point is the project and not the language, but how can you make the connections between your project and the language if you do not know what they do? This is why you might consider Angular 4!

What language does your browser speak?
Let us start from the beginning. If you do not know much about programming, the first thing you might want to do is to make a difference between software development and web development. You can develop software, which will never use an Internet connection or even a screen. In this case, however, we talk about web development. In other words, this is about developing web sites, pages or tools, which you can see and use in a browser.

Therefore, you have to start with the basic language supported by browsers, which is HTML. Everything you see in the browser are HTML elements: text, butttons, images, etc. You could definitely develop a website in pure HTML. In this case, you would have to write down the code for each page.

Now you might have, or not, heard of CSS, which is all about styling. For instance, you can give a title a red color without using CSS, by defining the color directly in the HTML code. CSS, however, allows you to centralize styling commands in one file. For example, you can set the text color of all titles in your webpage in one single line of code. It helps you “save code”. This means that you repeat yourself a lot less.

HTML and CSS have evolved considerably over the past few years. You can do a lot more with them than ten or twenty years ago and they are supported by all browsers. ‘Do more’ means that they offer you more possibilities (commands, elements, etc.). If you remember how websites looked in the past (if not use the Internet Archive), you know that they were more static, less fluid. They offered a somewhat poorer experience. This is because these languages provided less options and browsers did not support less of these options than the do today.

User interaction or background processing: frontend vs backend
When it comes to interactivity between the user and the website, you have to make yet another distinction: front-end and back-end. Front-end is what happens between your website and the user. Back-end is what happens in the background, which is (mostly) invisible to the user.

For instance, if you look up a flight on a booking website. You interact with the user interface, which designates the website that you see and manipulate with your mouse. However, when you hit the search button, the website starts processing your request in the background. For instance, it translates your research into a codified machine-readable request such as “get flights from X to Y at day Z”. This request is passed on to an API, which processes it and returns a list of flights. The user interface then presents the list in a human-readable way in your browser.

All major websites handling confidential or big chunks of data have a front- and a back-end. The front-end is the interface you can see in your browser, which lets you interact with content. The backend is the code run by a server in the background. Both parts of the website, front-end and back-end, interact with each other, but as a user you only interact directly with the front-end.

Where is your code executed : server-side or client-side
As stated above, every website is “rendered” in your browser. Rendering means that your browser reads the HTML and CSS codes and translate them into a visual interface (puts the logo on the top-left, shows the title in red, etc.). This “rendering” happens entirely on your computer, mobile or whichever device you use to view a webpage. Hence, the action is processed by the CPU of your device. This is called client-side.

If you developed a website in pure HTML and CSS, this would be a purely client-side website. Certain frameworks (you will discover further down what frameworks are) are called client-side frameworks because they rely solely on languages, which can be read directly by a standart browser: HTML, CSS, JavaScript. For instance, AngularJS or EmberJS are client-side frameworks.

Other languages, however, need a server to be executed. PHP for instance is one of them. PHP means Hypertext preprocessor. This means that you enter your code in PHP language, which is then translated (pre-processed) into HTML (hypertext). Basically, a small piece of software is executed to translate the code into a language which can be read by the browser. As no user ever would allow a website to execute software only to present its pages in his or her device (for safety reasons), the preprocessor is executed on a server. Hence, server-side.

So, back to our example: if you want to develop a complex website, you will have to choose both a front-end and a back-end environment. Whereas the back-end is most probably executed by a server-side language or framework, the question whether it is server- or purely client-side is more open for the front-end.

Language vs framework
One of the major difficulties I had when catching up with today’s state of web development was to make the difference between languages, frameworks and libraries. I would say Python, they would say Django. I heard Rails, they meant Ruby. You might be best advised to think of them as families. In each language family, you might find have frameworks and libraries, serving as front-end or back-end solutions, being executed client- or server-side.

In the JavaScript family for instance you have node.js the server-side framework, jQuery the library, AngularJS the client-side framework and many many more. Note that certain frameworks and libraries also interact with each other. Some of them are interdependent, others are incompatible.

Frameworks, libraries, pre-processors : it is all about making it easier for you!
So what is the big deal about using frameworks? After all, you can simply write your code in, let us say, JavaScript and it works perfectly. This is definitely an option. (And this is actually what I did for a long time…) You can, but why would you renounce to all the nice tools they offer you to make site navigation in a few steps, to secure your website, to handle the data flow safely, etc.?

Frameworks help you organize your website and all the code chunks in a clean and efficient way. They automize the creation and interconnection of your elements. They offer built-in functionalities which save you tons of code. They make sure your website performs well and safely.

Libraries are basically code chunks, written for you. You want to design an dropdown menu? Build it by inserting a few lines of code rather than figuring it out all by yourself using 100 lines of code. Libraries help you focus on your key functionalities while minimizing your time spent on things that have been done over and over again.

Pre-processors make your code more readable, less redundant and less error-prone. TypeScript for instance, which processes your TypeScript code into browser-supported JavaScript code, helps you defining all your variables, objects and methods in a cleaner way. Sass and Less on the other hand, which translate into browser-supported css, let you organize your styling code (css) more efficiently.

This long list of currently popular languages, frameworks and libraries for web designers might give you a hint on what does what exactly.

Now what the heck is Angular 4?
Angular is…

  • a framework: therefore it is not a language, but an environment.
  • ideally used as a front-end solution. It was built on that purpose.
  • can be executed both client-side and server-side
  • part of the JavaScript family: code is written in TypeScript and JavaScript.
  • totally different from AngularJS. Even tough it is an evolution of it, there is a big gap between AngularJS and Angular2, the predecessor of Angular 4. Yup, Anuglar 3 is a bit like Windows 9.

And the best back-end solution for Angular4 is…
*drum rolls* …whatever you like! As a matter of fact, the choice of the front-end solution does not have any impact on the type of back-end solution. The only pre-requisite is to make sure they interact with each other correctly. This is not a matter of languages, let alone frameworks. It is all about convenience. Check this quora conversation on the topic where Opesanya clearly hits the nail on the head. Convenience would push you towards other JavaScript-based solutions such as Express.JS.

I hope this helped you find your way in the wide world of web languages! If you see any inaccuracies, please leave a commment.

Leave a Reply

Your email address will not be published. Required fields are marked *