Dan Harper’s Post

JavaScript Obfuscation is a nightmare. I cannot imagine how difficult it would be if we humans will have to write in machine code directly because its really difficult to understand by humans. This is the JavaScript Obfuscation. Generally JavaScript is easy to understand and very loving as well. But do you know if you will deliberately write obfuscated javascript code then world's most popular programming language might become world's most disgusting as well. Let me give you an example of writing a Javascript function : function greeting() { console.log("Hello, welcome to JS world"); } it makes sense, even if you are not a programmer still you can understand what this code is probably doing. This is human understandable code and a pure javascript code. But machine cannot directly understand above code. The machine understands this code : eval(  (function (p, a, c, k, e, d) {   e = function (c) {    return c;   };   if (!"".replace(/^/, String)) {    while (c--) {     d[c] = k[c] || c;    }    k = [     function (e) {      return d[e];     },    ];    e = function () {     return "\\w+";    };    c = 1;   }   while (c--) {    if (k[c]) {     p = p.replace(new RegExp("\\b" + e(c) + "\\b", "g"), k[c]);    }   }   return p;  })(   "2 1(){0.3('4, 7 6 5 8')}",   9,   9,   "console|greeting|function|log|Hello|JS|to|welcome|world".split("|"),   0,   {}  ) ); This is obfuscated javascript code and this is the exact same code which will return the same thing like the previous one javascript code. This time its machine understandable but not human understandable. What a big conflict between humans and machines.

Read of the Day: Day 8 📖 Article: Understanding JavaScript Promises 🌟 Key Takeaway: JavaScript Promises simplify asynchronous programming by providing a cleaner way to handle operations like API calls, file loading, and timeouts. • Core Concepts: 1. States of a Promise: • Pending: Initial state, neither fulfilled nor rejected. • Fulfilled: Operation completed successfully. • Rejected: Operation failed. 2. Syntax: const promise = new Promise((resolve, reject) => { if (success) { resolve("Task successful"); } else { reject("Task failed"); } }); 3. Chaining Promises: • Use .then() for handling success. • Use .catch() for handling errors. • Use .finally() for cleanup actions. 4. Async/Await: • A modern way to handle promises: async function fetchData() { try { const response = await fetch('https://lnkd.in/eqzamZhR'); const data = await response.json(); console.log(data); } catch (error) { console.error(error); } } fetchData(); ✨ Why it’s Useful: Promises prevent “callback hell” and improve code readability, especially when dealing with multiple asynchronous operations. 📌 Pro Tip: Always handle rejections to avoid unhandled promise errors! Use .catch() or a try/catch block for robust error handling. https://lnkd.in/eC9ishJi #JavaScript #Promises #AsyncProgramming

Line-by-line interpretation is a time-taking process. So, modern javascript engines have a work-around to cater to that need for speed. It's a pretty neat trick called Just-In-Time Compilation. Just-in-Time compilation is done alongside interpretation at runtime. It's different from the Ahead-of-Time compilation which happens before execution and which we will cover in the next post. So, what happens in Just-in-Time compilation? In JIT-compilation, the code is compiled into machine code "just in time" when the program runs i.e during execution. Here's the script of the process: The source code is typically (not always) first compiled into an intermediate representation (e.g., Java bytecode or .NET MSIL). Otherwise it's the source code that is just-in-time compiled. As for those who do not know what intermediate representation is: Intermediate representation is a form of code that acts as a bridge between the high-level source code and the low-level machine code. It is not understandable by the CPU until converted into machine code; and that's exactly what JIT-compilation does. It converts the re-usable parts (hot paths) of the code (which is either the source code or its intermediate representation) into machine-code and caches it in the memory for later use. In this way, while the interpretation translates and executes the non-reusable code line-by-line, JIT-compilation transforms the reusable code into machine code and stores it for later use. This results in faster execution because the code does not have to be translated into machine-code every time each line has to execute. Examples like Google’s V8 engine (used in Chrome and Node.js) and Mozilla’s SpiderMonkey demonstrate how JIT works with features like baseline compilation, type inference, and optimization phases. If the assumptions made during JIT compilation are invalidated (e.g., a variable changes type unexpectedly), the engine might revert to interpretation or recompile the code. #javascript #techforstartup #learntocode #frontend #backend

Master the hottest frameworks! That’s exactly what I aimed to do when I first started learning to code. But as I grew from a beginner to where I am now, my mindset shifted. Junior Me: “I need to master React! Which framework should I learn next?” Mid-level Me: “Let me explore new tech stacks and tools!” Senior Me: “Wait... aren’t these all just the same patterns repeating themselves?” I realized: -Frameworks come and go (Remember jQuery?) -Design patterns stay relevant for decades -System architecture principles remain steady -Problem-solving patterns are timeless And a few things I wish I had learned sooner: -Angular, React, or Vue are just tools -The underlying patterns are what really matter -Understanding 'why' over memorizing 'how' -Fundamentals > framework specifics Think about it: -MVC existed before the web -Dependency injection isn’t tied to any framework -State management is a concept, not a library The frameworks you learn today might be outdated in 5 years. But the patterns you understand will serve you for life. If you’re new to coding, my advice is: don’t skip learning patterns just because your framework makes them “unnecessary.” Frameworks have an expiry date, but fundamentals don’t. What patterns have you noticed repeating across different frameworks?

Dependency injection/IoC in front-end frameworks, here are some thoughts with an example in React. https://lnkd.in/gQMPF82E

Do you know why JavaScript is called a dynamic language? A dynamic language is a language that allows changing the type of variables, adding new properties or methods to objects, or even changing the prototype of objects at runtime. This means that you can write flexible and expressive code without worrying about strict rules and restrictions. 😎 JavaScript is a dynamic language because it supports all these features. For example, you can assign different types of values to the same variable, such as: let x = 42; // x is a number x = "Hello"; // x is now a string x = true; // x is now a boolean You can also add new properties or methods to any object, even built-in ones, such as: let person = { name: "Alice", age: 25 }; person.hobby = "Coding"; // add a new property person.sayHello = function() { // add a new method console.log("Hello, I'm " + this.name); }; person.sayHello(); // call the new method You can even change the prototype of an object, which is the object that provides inheritance and shared properties and methods to other objects. For example, you can change the prototype of person to another object, such as: let animal = { species: "Human", legs: 2 }; Object.setPrototypeOf(person, animal); // change the prototype of person to animal console.log(person.species); // Human console.log(person.legs); // 2 These are some of the reasons why JavaScript is a dynamic language. Dynamic languages have many advantages, such as ease of use, flexibility, and expressiveness. However, they also have some drawbacks, such as performance issues, debugging difficulties, and security risks. Therefore, it is important to use them wisely and carefully. 🙌

🚀 Is JavaScript an interpreted or a compiled language❓ I was once asked this question in an interview, and I confidently answered that it is an interpreted language. 🙊 Even though it is partially true, that is not entirely the case. JavaScript is a just-in-time (JIT) compiled language. Before the code is interpreted, the compiler compiles the code and creates the Abstract Syntax Tree (AST) for execution. That being said, what I want to emphasize today is hoisting in JavaScript. Hoisting happens during the compilation process and only functions, and variables declared with "var" keyword are hoisted on top of the scope. JS compiler treats function declaration and var keyword differently, whenever it encounters any of them, the compiler creates an entry to the AST and hoists the declaration to the top of the local scope. From example 1 we can see that the output is undefined, instead of 10. If variable declaration is hoisted, then the output should be 10, right? 🤯 Unfortunately, JS compiler treats declaration and association separately, it hoists only the declaration. The code block from example 1 will look something like this during execution: { var foo; console.log(foo); foo = 10; } The same is not true for variables declared with let, and const. They are executed in place. 💡 There is another interesting problem. I want you to figure out what would be the output of the below code block, and why? ---------------------- foo( ) var foo = function( ) { // do something } ----------------------

Myth: "Frameworks make you a better developer." Misconception: Many believe that using popular frameworks (like React or Angular) automatically improves their skills. Reality: Relying too heavily on frameworks can obscure foundational programming concepts. Here are key points: Fundamentals Matter: Understanding JavaScript, HTML, and CSS is crucial. Frameworks don't replace the need for these skills. Framework Limitations: They are opinionated tools designed for specific problems, which can limit flexibility. Over-Reliance on Tools: Using a framework without understanding its underlying concepts can lead to bad practices. Obscured Problem-Solving: Jumping into frameworks might bypass essential problem-solving skills. Adaptability Issues: Frameworks can change or become obsolete. Mastering core principles allows for easier adaptation. Conclusion: Frameworks are helpful but mastering the fundamentals is essential for true growth as a developer. They are tools, not a measure of skill.

JavaScript's filter() method is fundamentally non-destructive, which is a crucial characteristic that sets it apart from many other array operations. At its core, this means that when you use filter(), it never changes or modifies the original array you're working with. Instead, it creates an entirely new array that contains only the elements that meet your specified criteria. The non-destructive nature of filter() is rooted in the principle of immutability in programming. This concept is particularly valuable in modern JavaScript development, where predictable data flow and state management are paramount. When you use filter(), you're guaranteed that your original data remains intact, which provides several significant advantages in application development. This behavior supports a more functional programming style, where data transformations create new values rather than modifying existing ones. It helps prevent unintended side effects in your code, as the original data structure remains unchanged and can still be referenced or used in other operations. In the context of larger applications, this non-destructive behavior becomes even more valuable. It enables easier debugging, as you can always refer back to the original data. It also facilitates features like undo/redo functionality, where you need to maintain different states of your data. Additionally, it makes your code more predictable and easier to test, as you can always be certain that your original data remains unaltered. The creation of a new array, while beneficial for data integrity, does come with memory implications. Each time you use filter(), you're allocating new memory for the resulting array. While this is rarely a concern in most applications, it's worth being aware of when working with very large datasets or in memory-constrained environments. Many JavaScript developers consider this non-destructive behavior a best practice. It aligns with the principles of immutable data management, which has become increasingly popular in modern JavaScript frameworks and libraries. This approach helps prevent bugs that can arise from inadvertently modifying data, especially in complex applications where multiple components might be using the same data. When considering performance, the non-destructive nature means that filter() will always have to create a new array, which has both memory and processing implications. However, for the vast majority of use cases, the benefits of immutability and predictable behavior far outweigh any potential performance considerations.

❌ 𝐒𝐭𝐨𝐩 𝐀𝐛𝐮𝐬𝐢𝐧𝐠 '𝐚𝐧𝐲':  𝐌𝐚𝐤𝐞  𝐭𝐡𝐞 𝐌𝐨𝐬𝐭 𝐨𝐟 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭 ❌ TypeScript is one of the most powerful tools in modern JavaScript development, but like any tool, its effectiveness depends on how you use it.  Unfortunately, I’ve seen many developers misuse 'any', turning TypeScript into "JavaScript with extra steps." 𝐖𝐡𝐲 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐔𝐬𝐞 '𝐚𝐧𝐲' 𝐄𝐯𝐞𝐫𝐲𝐰𝐡𝐞𝐫𝐞 𝐒𝐡𝐨𝐫𝐭-𝐭𝐞𝐫𝐦 𝐜𝐨𝐧𝐯𝐞𝐧𝐢𝐞𝐧𝐜𝐞: Need a quick fix? Just slap an 'any' on it! 𝐃𝐞𝐚𝐝𝐥𝐢𝐧𝐞 𝐩𝐫𝐞𝐬𝐬𝐮𝐫𝐞: When speed outweighs quality, developers default to the easiest path. 𝐖𝐡𝐲 𝐓𝐡𝐢𝐬 𝐀𝐩𝐩𝐫𝐨𝐚𝐜𝐡 𝐢𝐬 𝐇𝐚𝐫𝐦𝐟𝐮𝐥 𝐃𝐞𝐟𝐞𝐚𝐭𝐬 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭’𝐬 𝐩𝐮𝐫𝐩𝐨𝐬𝐞: any bypasses the type-checking benefits that TypeScript provides. It's essentially turning off the guardrails. 𝐈𝐧𝐭𝐫𝐨𝐝𝐮𝐜𝐞𝐬 𝐛𝐮𝐠𝐬: Without type safety, errors can creep in , the very thing TypeScript is supposed to prevent. 𝐇𝐮𝐫𝐭𝐬 𝐦𝐚𝐢𝐧𝐭𝐚𝐢𝐧𝐚𝐛𝐢𝐥𝐢𝐭𝐲: Codebases littered with any become a nightmare for collaborators, especially when debugging or refactoring. 𝐇𝐨𝐰 𝐭𝐨 𝐁𝐫𝐞𝐚𝐤 𝐭𝐡𝐞 '𝐚𝐧𝐲' 𝐇𝐚𝐛𝐢𝐭 💪💻 𝐒𝐭𝐚𝐫𝐭 𝐬𝐦𝐚𝐥𝐥: Use unknown instead of any to enforce stricter handling. 𝐄𝐦𝐛𝐫𝐚𝐜𝐞 𝐠𝐫𝐚𝐝𝐮𝐚𝐥 𝐭𝐲𝐩𝐢𝐧𝐠: Not every part of your app has to be strongly typed at once. Incrementally add types to the most critical parts first. 𝐋𝐞𝐚𝐫𝐧 𝐚𝐝𝐯𝐚𝐧𝐜𝐞𝐝 𝐓𝐲𝐩𝐞𝐒𝐜𝐫𝐢𝐩𝐭: Invest time in understanding generics, utility types, and type inference. These tools allow you to write expressive, reusable code without relying on any. #Coding Tags for better reach: Digvijay Rajput Rajat Gajbhiye Ajay Suneja 🇮🇳 ( Technical Suneja )