How did you survive this migration?

[Nand32]

As a traditional (non-script) developer, who always starts the code with proper class, methods etc in C++/Java,

class ApiClient
{
ApiClient(){}
getSomething(){}
putSomething(){}
}

This always looked so clean for my eyes.. Now compare it with JS/Typescript code :

class ApiClient {
public get(apiURL: string): Promise{

return new Promise((resolve, reject) => {
  const options = {
    method: 'GET',
    headers: {
      'Content-Type': 'application/json',
      // Add any other headers as needed
    },
  };

  const request = http.request(apiURL, options, (response) => {
    let data = '';

    response.on('data', (chunk) => {
      data += chunk;
    });

    response.on('end', () => {
      if (response.statusCode === 200) {
        const responseData = JSON.parse(data);
        resolve(responseData);
      } else {
        reject(new Error(\`Error: ${response.statusCode}, Response: ${data}\`));
      }
    });
  });

  request.on('error', (error) => {
    reject(error);
  });

  request.end();
});

}
}

Why do they want to write the whole code into the ()? It's almost like writing all the code inside (..) in a C++ function.. where we just expect the params & arguments. like:

ApiClient(.....Write the whole code here? What? :( ){}

Seriously I have so much pain tracking where the brackets begin and end if I'm reviewing a .js code snippet. Did C++/Java also move into this Anonymous function hype? Looks like I'll have a pretty steep learning curve on any direction. Hating this. :| How did you survive this? If you happen to a non-JS developer migrating into the JS world?

[11917640 Member]

Nand32 wrote:

How did you survive this?

I didn't. I am dead.

[honey the codewitch]

There's a similar issue with C# post 6 where anonymous functions and various shorthands obscure the code. The simple answer to how I deal with it is I don't. I rarely have to read such code, and I tend to have 100% control over my codebase and the tools I use, plus I have to target toolchains that are too old to do C++20. I feel your pain. I started coding 1986 procedurally in BASIC, then in 6502 machine code, finally in the Apple mini assembler before moving to PC. I picked up OOP fine, and then even Generic Programming in C++ but beyond that it starts to lose me and I go cross eyed. I don't even like LINQ.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

[Amarnath S]

Nand32 wrote:

Seriously I have so much pain tracking where the brackets begin and end if I'm reviewing a .js code snippet.

VS Code has an free add-on (forgetting it's name, but I've installed it on my machine) which matches brackets, rather displays matching brackets with the same colour, which I find very useful.

[MarkTJohnson]

It's a setting, Editor > Bracket Pair Colorization. I have it Enabled.

I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.

[raddevus]

I totally understand your pain. I came from a similar background -- started learning C++ in 1993 (along with MFC Microsoft Foundation Classes -- which was really an amazing implementation of OOP). Those were the days that OOP was coming on strong, then Java was invented and everything was an object so really OOP design principles became even more codified. Then, JavaScript...a dynamic language where it seemed there were no rules and didn't originally even have a way to create a class. Instead you had to create a function that acted like a class. Slowly, things moved toward functional programming and the syntax can be so austere that you just can't even see what is going on. Interfaces - In The OOP World In the OOP world, we had Pure Abstract classes (in C++) and then Interfaces. We could see that these described "contracts" of functionality: A bunch of functions that the classes would implement. Remember what an Interface really is: it is the promise that the classes will have functions with specific names that will be implemented in the future. This allows you to have a DYNAMIC function. A function that can be changed in the future. Dynamic Programming Languages But, then on the dynamic programmning side (JavaScript) they had functions as first-class objects. That meant you could pass in a function to a function and override the original functionality that could be run. Altering Functions Any Time Anywhere In other words they allowed a dev to write a function that could later be altered easily by anyone. For example:

var myFunction = (param1, param2) { // do all kinds of stuff}

Then later someone could come along and be like, "Oh, I need that function to do XYZ..."

myFunction = (param1, param2) { // do all the NEW STUFF!!!}

But then this idea got inside people's heads and they were like,

New Devs undisciplined idea:

Anything can be anything!!!! Any function can just do a new thing.

In the C++ world we learned "design" (ideas to create structures which were later extendable, maintained, added to, etc.) but in the JavaScript world these ideas were "backed into" --- people started typing code and then later (maybe) learned some design principles. They just go the idea that, "Hey, you can do anything, anytime." For me, I finally learned "Functional" programming when I started learning Kotlin (Android programming) and Swift (iO

[Alister Morton]

A witch after my own heart - learn and use what you need, ignore what you don't.