Discussion on: To Typescript Or Not To?

[Nikola Stojaković]

Exactly because of that. TypeScript will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript. As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.

And who ever said that TypeScript solves this? No one ever said that TypeScript could be used as a static typed language (like Java or C#) but for writing large JavaScript projects. TypeScript gives you the tools to better describe your entities in the code base or shorter said, self-document your code. When you turn on strict mode and use strong enough code standard (like AirBnB), you'll catch large number of potential pitfalls.

Regarding the third party checks, there are various libraries which allow you to do this, like class-validator. With them, you can do the check on the input data of your applications.

With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be.

And that's exactly the problem which makes all dynamic languages bad for large projects. It's been empirically proven that large projects benefit from using types.

link.springer.com/article/10.1007/...

You can combine the two ways, but what is the point then? If you will spend time writing definitions and then spend time writing code to ensure these definitions are maintained during runtime, why have them in the first place? You can do the same in JS defining your type-checks and the result will be the same but clearer.

How would you do it in JS? Checking type of each construct at each step? As I said, you already have validation libraries, which, combined with TS, can help you to remove most of the possible pitfalls.

I won't comment the second point because it's subjective. I find TypeScript pretty readable.

TypeScript is said to solve JavaScript’s problems. But it does not. Dynamic typing was never a problem in JavaScript, but many other gotchas such as NaN === NaN being false, semicolons being optional or not optional, a linebreak changing an object definition into a scope, syntactic sugar in place of OOP are indeed problems. TypeScript does nothing to solve them, but introduces yet another standard, further polarizing the JS community.

The sole fact that TypeScript prevents you from doing dumb things like adding numbers and strings (yes, implicit conversion is the devil's work) proves that it in fact solves the problem. The problems you listed could be at least partially solved by imposing restrictions. It's not possible to make a complete solution for these things because we have to maintain backward compatibility with huge number of sites written in the JS which use these quirks.

And yes, dynamic typing is a problem as I said, once you hit certain point in your project. That's the first reason TS was made in the first place.

TypeScript is something that compiles into JavaScript, it cannot be a superset by definition.

TypeScript is a superset because it is JavaScript + various other constructs on top of it's syntax like interfaces, enums, generics etc. Just because it compiles to pure JavaScript doesn't mean it's not a superset.

Regarding number five I don't have anything to say since I'm using both open source and proprietary technologies in my work. I care about getting the job done more (but I prefer open source solutions for various reasons).

Regarding number six, we can agree that just because many people use something doesn't mean it's a good tool. But if so much big open source projects have moved to TS and told that it made their development easier, I'll trust them. Especially because it made mine much easier and less stressful.

As you said it adds transpiling time which is something that you definitely don't want. Most companies choose JS (or PHP or Ruby or...) for being interpreted languages which means you avoid compiling/transpiling every single time and you end up with faster development.

Today you still have to do various building processes whether you're using the TS or not (the Babel you mentioned for example) so it's not that big difference. TS compiler is pretty fast and there is also Deno which runs TS out of the box, without compilation to JS.

If you really feel in need to get strong typing you just need to search "strong typing js babel plugin" and you'll find many approaches that can fit for you or for your project.

It is nowhere near TS which has one of the most advanced type systems out there with support for structural and algebraic types.

[Roman K]

Let me disagree on "typescript is for large projects": the thing is once the project turns into "large" - it's too late for TS. I've been on various large JS projects, and all people prayed and talked like "let's switch to TS", "soon we will do it". But that's never happened - too much time and effort to migrate. Just imagine a complex js file with a lot of untyped variables, and you have to write types without having any idea of what's happening here - it's too hard.

[Nikola Stojaković]

Of course, I was thinking about projects which tend to become large (although you can't predict that easily - I use it for every JS project I'm starting out these days).

[Vagrant Jin Kazama]

TS which has one of the most advanced type systems out there

TS compiler is pretty fast and there is also Deno which runs TS out of the box, without compilation to JS.

And that's exactly the problem which makes all dynamic languages bad for large projects. It's been empirically proven that large projects benefit from using types.

Your answer reads like an ode to complexity. I feel I have to defend the "old" languages.
Complexity justifies the high salaries developers command for their monthly paycheck, rather than good, simple, clean, readable code.

And to further my status as a consultant and heathen, why is JS being used everywhere? If you yourself say static typed languages are superior, why not use a static-typed language, instead of added complexity and overhead to bend the time-space continuum of a dynamically typed language to do the work? Why not use C# or Java on the backend? Why add an order of magnitude more complexity to client side code?

You know the answer. I know the answer. Cleverness.

[Nikola Stojaković]

Your answer reads like an ode to complexity. I feel I have to defend the "old" languages.
Complexity justifies the high salaries developers command for their monthly paycheck, rather than good, simple, clean, readable code.

Your thoughts come from the wrong premise. Types don't add to the complexity that much. Yes, it's more work, but it will be complex as much as your project is complex.

Java is not inherently more complex just because of it being static typed. It's more complex because of it's huge ecosystem and the things you can do with it. Java on it's own is pretty straight forward language. TypeScript too. Types don't change that.

I'm always for the simple, clean and readable code and that's exactly one of the reasons why I prefer TypeScript - because I can clearly see what my method takes as arguments and what it will return. The code is self documenting.

And to further my status as a consultant and heathen, why is JS being used everywhere?

It's not used everywhere. We can easily get that impression if we're working solely on the web or we heard how it can be used for embedded applications, desktop applications and so on. Just because something can be used in many places doesn't mean it should be.

PHP could be used for writing desktop applications too, and how many popular desktop applications you know which are written in it? Compared to that there are some popular desktop applications written in JS but most of them suffer from performance issues when you're trying to deal with more CPU intensive stuff. VS Code is an exception because Microsoft invested heavily in making Electron more performant.

If you yourself say static typed languages are superior, why not use a static-typed language, instead of added complexity and overhead to bend the time-space continuum of a dynamically typed language to do the work? Why not use C# or Java on the backend? Why add an order of magnitude more complexity to client side code?

Because I don't get to choose which language we will use on the project. I'm working as a full stack developer on mostly JS projects which all use TypeScript. If I'm given a chance to choose between TS or JS, I'll choose TS. If I'm given a chance to choose between JS and X language for the back-end, where X is Java, C#, Elixir (which is dynamic typed language by the way) or some other technology interesting to me and suitable for the project, I'll choose X.

So yeah, I would use C# or Java on the back-end if I had chance.

You know the answer. I know the answer. Cleverness.

Nope, just gave you the answer above. It's about business decisions.

[JoelBonetR 🥇]

I've something to say in here.

• Java is complex because it adds so many boilerplate that it makes it hard to read. Kotlin solves some points of that but not all of them as well.

example of java code:

public static String testableHtml( PageData PageData, Boolean IncludeSuiteSetup) {
   PageData foo = new PageData( PageData );
   String a = foo.getName();
   // do stuff

   return  a;
}

How this can be more readable?

/* @ params
* PageData, Boolean
* return String
*/
public static testableHtml ( PageData, IncludeSuiteSetup ) {
    foo = new PageData( pageData);
    Sring a = foo.getName();
   // doStuff;
  
   return a;
}

It's a simple example where not so bloatware is added but imagine that on a really big project, having to read the types all the time of you try to figure out what the code does. if you equal a var to a given type, it's inherent that it will take this type.

TS does a better job than Java in this point, for example.

PHP could be used for writing desktop applications too,

When I was a young dev there was a framework for doing that. Of course it embedded an Apache server (I guess) that were virtualised inside this environment to reach that. It was slow because the current tech didn't exists.

PHP like any other interpreted language nowadays is compiled when interpreted for the first time so the server can read the compiled version to run faster. Same happens with JS or Ruby to say some. It also wasted resources to raise this "VM" environment on a time where resources were more limited than nowadays.

Each language has 1 or more runtime environments and PHP as desktop APP have some throwbacks for it not being recommended.

JavaScript by the other hand has to consume notably less resources to run and has an advantage for the implicit way it runs, which leads to more efficiency than PHP (we can enter in more detail about that whenever you want).

... I'm working as a full stack developer on mostly JS projects which all use TypeScript. If I'm given a chance to choose between TS or JS, I'll choose TS. If I'm given a chance to choose between JS and X language for the back-end, where X is Java, C#, Elixir (which is dynamic typed language by the way) or some other technology interesting to me and suitable for the project, I'll choose X.

As I've said before TS is good but using always TS is usually a lack of previous analysis of what you really need. There's no tech to rule them all and all of them cover some needs.
If you are going to make a whatsapp knock-off or audio stream such spotify, you can use Java to deal with this Async operations, which will be a pain in the ass compared to using JS over Node, the dev time will increase notably and the end result will not differ much from one implementation to another, so there's no reason for not using JS on that (to say something).

As second example (and the last to not extend this comment more) would be using TS on a simple Node API that's a CRUD for -let's ssay- email and password of the user profile.

You'll end up with 50-70 lines of code as much, they will be listeners to some route with some resolver in it, well structured. There's no real need or concern that leads you to use TS here. The same way not all things have to be OOP.

Again, analysis part is one of the most important things when starting a project or a new feature. Then having your code to work is half the job while cleaning your code is the other half.

Stay save and code tests,

best regards :)

[Nikola Stojaković]

Java is complex because it adds so many boilerplate that it makes it hard to read. Kotlin solves some points of that but not all of them as well.

Again, this is subjective opinion. Just because there is more to read doesn't mean it's inherently harder to read - you just have more information, but I only see this as a plus because there is no place for ambiguity compared to reading JS (except if you're writing JSDoc, which is less ideal solution than having types where declarations are).

You ask how this can be more readable - it's pretty easy to read for me. Right away I see it's a static method which returns string and takes too parameters, one which is an instance of the PageData and other which is a boolean. I don't understand what's so unreadable here.

It's a simple example where not so bloatware is added but imagine that on a really big project, having to read the types all the time of you try to figure out what the code does. if you equal a var to a given type, it's inherent that it will take this type.

You don't have to spend all your time reading types. Java also introduced var some time ago so you don't have to write huge lines anymore. Most of the types you'll work with will be straightforward, except if you're working on something more complex, in which case it would be of even bigger help to have types in the first place.

JavaScript by the other hand has to consume notably less resources to run and has an advantage for the implicit way it runs, which leads to more efficiency than PHP (we can enter in more detail about that whenever you want).

I agree, but the fact stays that it's not good for CPU intensive tasks (except if you're using some multi threaded environment which are rare - Electron uses V8).

As I've said before TS is good but using always TS is usually a lack of previous analysis of what you really need. There's no tech to rule them all and all of them cover some needs.
If you are going to make a whatsapp knock-off or audio stream such spotify, you can use Java to deal with this Async operations, which will be a pain in the ass compared to using JS over Node, the dev time will increase notably and the end result will not differ much from one implementation to another, so there's no reason for not using JS on that (to say something).

If I need to use JS, I don't need any specific analysis for TS because TS is JS after the compilation step kicks in. JS with much less headaches in every sense. There is no one technology to rule them all, but when I see that JS is suitable, even if I'm going to write a small CRUD app with few routes. It's because TS gives me so many benefits over using purely JS and I mentioned these benefits before. Why would I make my life harder if I don't have to?

If you are going to make a whatsapp knock-off or audio stream such spotify, you can use Java to deal with this Async operations, which will be a pain in the ass compared to using JS over Node, the dev time will increase notably and the end result will not differ much from one implementation to another, so there's no reason for not using JS on that (to say something).

It doesn't have to be pain in the a** if you know what you're doing. There is Akka. If you need to do CPU intensive stuff on top of dealing with async operations it makes more sense to use Java. If you don't and your developers know JS better, it makes more sense to use Node. There are many questions you have to answer before choosing a technology and there are reasons not to use JS even if you're doing async stuff - if it wasn't the case no one would use Go, Elixir, Erlang and other languages for that purpose.

[JoelBonetR 🥇]

Again, this is subjective opinion. Just because there is more to read doesn't mean it's inherently harder to read

Yes it is, and it's nothing new, in times of Aristotle they already studied how the way to spell/write things down can change the perception and the attention of the people.
If you say/write something concisely, using the context people will bring more attention but if you add repetition and don't use the context people simply stop paying attention to your speech or text.

This, in programming languages (remember that it's just a language, not to communicate between people but to communicate with a machine, even that, who had to read this language are other people as well) is translate as which we know as boilerplate.

the java syntax (unless you use var, ok) is repetitive and doesn't make use of conversational context.

String a = "foo";
String b = a;

you need to declare the type on the second one even being a copy of the first.

let's set an example in prose:


The women were in the blue house at the top of the mountain, waiting for the sunset.
The blue house at the top of the mountain was being stalked by an strange creature, but the women feel safe inside the blue house at the top of the mountain.


It's detailed, of course but it's hard to keep your attention to this and remember all the stuff you are reading, because people have context, and we're animals that like other animals, want to reach a given situation as fast or efficient as possible, so we like to read like this:


The women were in the blue house at the top of the mountain, waiting for the sunset.
The house was being stalked by an strange creature, but they feel safe inside the house.


Knowing what is easier to read it's a scientific fact and not an opinion.

---

If you need to do CPU intensive stuff on top of dealing with async operations it makes more sense to use Java. If you don't and your developers know JS better, it makes more sense to use Node. There are many questions you have to answer before choosing a technology and there are reasons not to use JS even if you're doing async stuff - if it wasn't the case no one would use Go, Elixir, Erlang and other languages for that purpose.

You can simply set a Node server to handle requests and resolve CPU intensive tasks specifically inside Python or Java or... APIs/web services.
You can benefit of faster development production and good performance as well. Having devs knowing a specific tech is an important part of the decision but never should be the most important part.

It's cheaper to pay a course to your devs and develop with the right current stack than using a wrong one because is "what they already know". Also devs usually like to learn new things so they'll feel like they are learning on it's current job and will probably be more excited about starting on a greenfield with a new tech.

---

If I need to use JS, I don't need any specific analysis for TS because TS is JS after the compilation step kicks in. JS with much less headaches in every sense. There is no one technology to rule them all, but when I see that JS is suitable, even if I'm going to write a small CRUD app with few routes. It's because TS gives me so many benefits over using purely JS and I mentioned these benefits before. Why would I make my life harder if I don't have to?

Here I let you a simple get and put verbs from an hypothetical API (there's a nonsense on adding the rest of the verbs because it will be a repetition of those actions mostly) with dummy data.

Do the exercise and translate this into TS and show which benefits can you get from that:

const Joi = require('joi');
const express = require('express');
const app = express();

const courses = [
    { id: 1, name: 'First Course 1' },
    { id: 2, name: 'Second Course 2' },
    { id: 3, name: 'Third Course 3' },
];

app.get('/api/courses', (req, res) => {
    res.send(courses);
});

app.put('/api/courses/:id', (req, res) => {
    const course = courseExists(req.params.id);
    if (!course) return res.status(404).send('The course with the given ID was not found');
    
    const { error } = validateCourse(req.body);

    if (error) {
        let errorMessage = '';
        error.details.forEach( err => {
            errorMessage += err.message
        });
        return res.status(400).send( errorMessage );
    }

    course.name = req.body.name;
    res.send(course);
});

function validateCourse(course) {
    const schema = Joi.object({
        name: Joi.string().min(3).required()
    });
    return schema.validate(course);
}

function courseExists( id ) {
    const course = courses.find( c => c.id === parseInt(id) );
    return course;
}

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on port ${port}...`));

[Nikola Stojaković]

If you say/write something concisely, using the context people will bring more attention but if you add repetition and don't use the context people simply stop paying attention to your speech or text.

Can you show me exactly where is this repetition you're talking about? Because declaring something as a String and writing down the string precisely character by character later is not a repetition. Declaring a type and defining a value is not the same, and as I said, type inference is available in Java today, so there are even less reasons to talk about some repetition, especially when it makes code clearer to understand. When you write something like this;

const processQueue = ({ queue }) => {
  // do something with the queue
}

How do you know what's the queue? What it contains? What methods you can call on it? It's easy to read but it doesn't give you any information. Not to mention that you need to define type so that compiler can know what will that variable contain if you're not passing value immediately. Compiler can't predict what you're going to put in it.

This, in programming languages (remember that it's just a language, not to communicate between people but to communicate with a machine, even that, who had to read this language are other people as well) is translate as which we know as boilerplate.

Actually, programming languages we use today were developed so people can better communicate between themselves about what the program does. If that wasn't the case we would still use Assembly or other lower level languages.

Remember what Harold Abelson said;

Programs must be written for people to read, and only incidentally for machines to execute.

It's detailed, of course but it's hard to keep your attention to this and remember all the stuff you are reading, because people have context, and we're animals that like other animals, want to reach a given situation as fast or efficient as possible, so we like to read like this:

Except our jobs as a software engineers is not to look at things from the animalistic perspective but rationally.

It's the empiric fact that types make development easier by describing the possible way some data can be processed. Yes, you write more code, but it's an investment for the future. Next time I come to the part which was self-documented by using types I'll have much less troubles understanding what has to be done.

Having to spend a bit more time to read it is a trade-off which you have to pay for more thorough explanation, but that will remove ambiguity and possible problems in the future stemming from that. Slower is faster.

Knowing what is easier to read it's a scientific fact and not an opinion.

And as I already said - harder to read != more complex.

You can simply set a Node server to handle requests and resolve CPU intensive tasks specifically inside Python or Java or... APIs/web services.
You can benefit of faster development production and good performance as well. Having devs knowing a specific tech is an important part of the decision but never should be the most important part.

It's cheaper to pay a course to your devs and develop with the right current stack than using a wrong one because is "what they already know". Also devs usually like to learn new things so they'll feel like they are learning on it's current job and will probably be more excited about starting on a greenfield with a new tech.

Okay, now we're getting into nitty gritty details and I think you're not really getting me right, so let's put things straight.

I never said that some technology should be used just because developers already know it. It's one of the points you use to choose technology - as I said, there are many points you have to discuss. If we all know JS and JS is not the right thing to use, we won't use it. In your post, you made it look like JS is the only choice for doing async stuff - it isn't, nor it's the best one. It's just that, a choice. Whether someone will use it or not depends on many other factors as well. You can't ignore the fact that market also dictates the choice of technologies, otherwise many of them would never even be chosen anymore for the new projects.

Here I let you a simple get and put verbs from an hypothetical API (there's a nonsense on adding the rest of the verbs because it will be a repetition of those actions mostly) with dummy data.

Do the exercise and translate this into TS and show which benefits can you get from that:

const Joi = require('joi');
const express = require('express');
const app = express();

interface Course {
  id: number;
  name: string;
}

const courses: Course[] = [
    { id: 1, name: 'First Course 1' },
    { id: 2, name: 'Second Course 2' },
    { id: 3, name: 'Third Course 3' },
];

app.get('/api/courses', (req, res) => {
    res.send(courses);
});

app.put('/api/courses/:id', (req, res) => {
    const course = courseExists(req.params.id);
    if (!course) return res.status(404).send('The course with the given ID was not found');

    const { error } = validateCourse(req.body);

    if (error) {
        let errorMessage = '';
        error.details.forEach( err => {
            errorMessage += err.message
        });
        return res.status(400).send( errorMessage );
    }

    course.name = req.body.name;
    res.send(course);
});

function validateCourse(course: Course) {
    const schema = Joi.object({
        name: Joi.string().min(3).required()
    });
    return schema.validate(course);
}

function courseExists(id: number): Course {
    const course = courses.find( c => c.id === parseInt(id) );
    return course;
}

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on port ${port}...`));

I get multiple benefits;

• Right away I see what parameters my method takes and what it will return
• I won't be able to accidentally pass a course with the wrong structure (you may say it's really hard for this to happen because I'm just changing a single array, but there is still a possibility so - no need to risk)
• I get better help from IntelliSense
• Code is more ready for the future if I want to make the project bigger. I can just move interfaces to their own files and keep all the benefits I mentioned above.

[JoelBonetR 🥇]

now that's a well defined answer where you are right on everything not because you wanted to explain it since the beginning but just why I told you things that were inexact or "falsy" so you want to put the things straight like they are.

That is the kind of explanations that most people need because If it was true that I knew nothing about that and I were talking serious in my sentences, now I could understand what's going on there, even if it's a little bit.

That's the main purpose of this circus and in most cases it's not people not knowing things, it's that people (like you and myself) write down things without really analysing or going in detail, or finding which details are needed to fully understand the topic. Which is normal because we take for granted things that we already know.

I truly believe that if we can answer in comments or explain in posts the things like we do when we're pissed, newcomers could inherit this knowledge, connect the dots and maybe, some day -hopefully sooner than later- became better than us.

I've three more things to say:

1. Thanks you.
2. Sorry for making you loose some time.
3. You can be a good speaker/teacher/writer on this subjects when you want.

[Nikola Stojaković]

No worries. It was indeed an interesting exchange of thoughts. All the best!

[JoelBonetR 🥇]

Now that's what I expect to read from someone!

Those are the good points to consider about TS!
Even you adding more importance to strong typing that it would had on a good and tested software -regardless of the size- I'll explain myself.

we know that in a perfect world we would probably use TDD, trust our tests at the top of out structure, commit little chunks of code, add proper documentation (not only from devs, but also the features should be documented out of the software on a structured manner) and all IT roles in the project are covered by the best individuals on the industry and so on or we can even fantasise that there's a machine that codes. If we reach this situation for any reason, strong typing would never be a need, because you understand the software you work in and knows how it works, and even when facing a human error, there will be trust-able tests that points us in the right direction.

The need of adding strong typing raises to the moon when we have junior devs, rushing bosses, bad company culture and so on.

Apart from that, for a given piece of software you can discern how big it will be, you always can connect different software made with different technologies without issues so as long as it's decoupled enough and well scoped in it's tasks it will be fine either way.

If you need (need is the keyword here) strong typing, you should be working on something that implicitly needs it for any reason or something bad is happening in your development process. Knowing the cause of this need could be a game changer for you and your teammates.

Arguing that you want it "just in case" is also fine, why not?

You can add TS then if you want mix it with JS if you need it so it will be a good.

Then if we talk about performance, statically typed languages have better performance at run-time intrinsically due to not needing to check types dynamically while executing (it checks before running). Similarly, compiled languages are faster at run time as the code has already been translated instead of needing to “interpret”/translate it on the fly.

TS compiles to JS so there is no issue here on performance, it will -hopefully- be the same than using plain JS.

[Nikola Stojaković]

Those are the good points to consider about TS!
Even you adding more importance to strong typing that it would had on a good and tested software -regardless of the size- I'll explain myself.

Nope - in fact, if you look at my profile, you'll see that I left comment before in one thread where I mentioned the importance of testing. I never said that static types are more important than testing nor that they're sufficient.

I add the importance on static typing because it's been proven over and over that static typed programming languages are better for large scale projects.

strong typing would never be a need, because you understand the software you work in and knows how it works

It would be a need even in that case because humans are not perfect - even with the properly written tests it would be possible to make bunch of mistakes and to pass data of wrong types. Static typing prevents you from making dumb mistakes in the first place.

The need of adding strong typing raises to the moon when we have junior devs, rushing bosses, bad company culture and so on.

No, the need of adding strong typing exists because it has been shown that large scale project written in dynamic typed languages are much harder to maintain. That's one of the reason why TS even came to existence - Microsoft had huge JS code bases and saw how unmaintainable they become after some time (and I'm pretty sure Microsoft engineers do write tests and documentaion).

Types allow you to describe the data and relationship between different data. This allows you to much better predict possible pitfalls (for example, to check if your switch case incorporates all posible cases like Rust does) and so on.

What you're basically saying is that all these static typed languages in the existence today came to be just because there were some cranky bosses and junior devs who couldn't program in dynamic typed lanugages, which couldn't be further from the truth.

Apart from that, for a given piece of software you can discern how big it will be, you always can connect different software made with different technologies without issues so as long as it's decoupled enough and well scoped in it's tasks it will be fine either way.

You can't easily predict how big some software will be. Also, decoupling is a hard process. I know this because I have worked on many microservice based architectures. One bad step and it's easy to make a huge number of errors.

If you need (need is the keyword here) strong typing, you should be working on something that implicitly needs it for any reason or something bad is happening in your development process. Knowing the cause of this need could be a game changer for you and your teammates.

It makes work much easier in the long run. That alone is one of the reasons why I prefer it over the dynamic typing. Sure, that doesn't mean I don't use dynamic typed languages at all - I have a game which is written in Ruby for example.

[JoelBonetR 🥇]

Thanks for this kind of comments Nikola, in this discussion I'm playing the role of devil's lawyer but I know those things, I have a career since long time ago. In this platform sometimes I get frustrated because there are many people blind-following things and not even analysing what they should do. Explanations like yours, mines sometimes and other few should get more visibility.

I'll try to pick some time in few days and extract excerpts about all this post in a manner of question/concern -> answer, trying to add external sources for further information and so on for those who want to get more than a surface knowledge and understand the concepts.

In the meantime I'll try to counter some points of view to see how people argue it's opinions or experiences and let's see what can we learn about all those chunks of text! :)

I'll mention you all when this job is done