I came across a post on Twitter that I thought would be helpful to share with those who are struggling to find a structured way to learn Javascript on their own. Personally, I wish I had access to this information when I first started learning in January. However, I am grateful for my learning journey so far, as I have covered most topics, albeit in a less structured manner.
N/B: Not everyone learns in the same way; it's important to find what works for you. This is a guide, not a rulebook.
EASY
What is JavaScript and its role in web development?
Brief history and evolution of JavaScript.
Basic syntax and structure of JavaScript code.
Understanding variables, constants, and their declaration.
Data types: numbers, strings, boolean, and null/undefined.
Arithmetic, assignment, comparison, and logical operators.
Combining operators to create expressions.
Conditional statements (if, else if, else) for decision making.
Loops (for, while) for repetitive tasks. - Switch statements for multiple conditional cases.
MEDIUM
Defining functions, including parameters and return values.
Function scope, closures, and their practical applications.
Creating and manipulating arrays.
Working with objects, properties, and methods.
Iterating through arrays and objects.Understanding the Document Object Model (DOM).
Selecting and modifying HTML elements with JavaScript.Handling events (click, submit, etc.) with event listeners.
Using try-catch blocks to handle exceptions.
Common error types and debugging techniques.
HARD
Callback functions and their limitations.
Dealing with asynchronous operations, such as AJAX requests.
Promises for handling asynchronous operations.
Async/await for cleaner asynchronous code.
Arrow functions for concise function syntax.
Template literals for flexible string interpolation.
Destructuring for unpacking values from arrays and objects.
the bulk of the two biggest categories have been sorted into archive entries, so hopefully from here on out it should be a bit less intensive - not as much trawling through hundreds of files
also cleaning up code redundancies, general more quality of life stuff like having the script that writes up the entry html for sorted tags to also display a title with the subject or date. more sensible method for displaying the number of entries for each tag too.
tags themselves now have their own data structure so I can add more information to those too, which is nifty - I mainly had it in mind for hiding or displaying certain ones, subcategories, but it's also a neat way of giving more context
I will start playing around more with the entry layout... I think it'd be neat if the main landing page was set to display gallery highlights - I have a variable for flagging 'featured' entries I particularly like but haven't put it to use yet.
I'm really curious if this kind of pseudo-blog-post type of code has been well documented anywhere? I haven't really found much while looking for resources, more suggestions for third party blog websites. it's working really well for me. I cannot stress enough how grateful I am not to be fiddling with the individual html of 800+ archive entries and using javascript to write that for me.
One of the neat consequences of the design of the language I'm working on with operatives instead of macros and a modular categorical semantics, is that everything that would be a keyword or special operator in other languages can be an operative in ours, which means they can be replaced and changed and modified in user code. This means that in this language the problem of two different dependencies of the same project wanting to use different versions of the language reduces to the problem of different dependencies wanting to use different libraries, and no system of complicated features pragmas or standard command line arguments that grow and grow and grow over time is necessary. Instead we can just have different versions of the syntax as ordinary libraries, versioned, polyfilled, dependency injected. Similarly, the formally meaningful modular semantics system means that we can add and remove features without that being a global decision; an old library that uses an old semantics can be transported to a new semantics by a functor, and we can prove that the functor implements all the axioms of the original semantics in terms of the new semantics, and then the old library will work just like a native library on the new semantics, with all its types, code, proofs and properties available for use and to the optimizer. A library written next year and proven correct should still run correctly in 300 years with no maintenance specific to that library. The compiler will of course need maintenance to keep it running on new hardware generations and adopt new technology.
But this isn't just a speculative future thing. Right now, modular semantics are useful in writing a project that works on multiple targets. For example, it might be useful to write a library that does some math which can work when compiled to JavaScript, wasm, or native. These targets have huge differences between them, but with modular semantics it's possible to just write using the minimal set of primitives needed, working from abstract high level collection data structures and math operations, and then any project that works in a specific system can just request a version of your package transported to their system, and all the high level data structures and properties will be filled in with whatever their platform uses to interop at full native speed. This also works in reverse; code that runs in a webpage using webgpu can have different primitives available based on which device they will run on, and not only share common libraries and types between them but also use target specific features like garbage collection or warp level parallel operators, even if the code is mixed in a single file to collect both facets of the implementation of a specific feature, and the compiler will give a nice type error if one of them gets used in the wrong place.
Imperative Programming
Imperative programming describes a sequence of steps that change the program’s state. Languages like C, C++, Java, Python (to an extent), and many others support imperative programming styles.
Declarative Programming
Declarative programming emphasizes expressing logic and functionalities without describing the control flow explicitly. Functional programming is a popular form of declarative programming.
Object-Oriented Programming (OOP)
Object-oriented programming (OOP) revolves around the concept of objects, which encapsulate data (attributes) and behavior (methods or functions). Common object-oriented programming languages include Java, C++, Python, Ruby, and C#.
Aspect-Oriented Programming (AOP)
Aspect-oriented programming (AOP) aims to modularize concerns that cut across multiple parts of a software system. AspectJ is one of the most well-known AOP frameworks that extends Java with AOP capabilities.
Functional Programming
Functional Programming (FP) treats computation as the evaluation of mathematical functions and emphasizes the use of immutable data and declarative expressions. Languages like Haskell, Lisp, Erlang, and some features in languages like JavaScript, Python, and Scala support functional programming paradigms.
Reactive Programming
Reactive Programming deals with asynchronous data streams and the propagation of changes. Event-driven applications, and streaming data processing applications benefit from reactive programming.
Generic Programming
Generic Programming aims at creating reusable, flexible, and type-independent code by allowing algorithms and data structures to be written without specifying the types they will operate on. Generic programming is extensively used in libraries and frameworks to create data structures like lists, stacks, queues, and algorithms like sorting, searching.
Concurrent Programming
Concurrent Programming deals with the execution of multiple tasks or processes simultaneously, improving performance and resource utilization. Concurrent programming is utilized in various applications, including multi-threaded servers, parallel processing, concurrent web servers, and high-performance computing.
API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. It is a way for computers to share data or functionality, but computers need some kind of interface to talk to each other.
When you use an application on your mobile phone, the application connects to the Internet and sends data to a server. The server then retrieves that data, interprets it, performs the necessary actions and sends it back to your phone. The application then interprets that data and presents you with the information you wanted in a readable way. This is what an API is - all of this happens via API.
Building Blocks of API
There are three building blocks of an API. These are:
dataset
requests
response
Let’s elaborate these blocks a bit.
An API needs a data source. In most cases, this will be a database like MySQL, MongoDB, or Redis, but it could also be something simpler like a text file or spreadsheet. The API’s data source can usually be updated through the API itself, but it might be updated independently if you want your API to be “read-only”.
An API needs a format for making requests. When a user wants to use an API, they make a “request”. This request usually includes a verb (eg: “GET”, “POST”, “PUT”, or “DELETE”), a path (this looks like a URL), and a payload (eg: form or JSON data). Good APIs offer rules for making these requests in their documentation.
An API needs to return a response. Once the API processes the request and gets or saves data to the data source, it should return a “response”. This response usually includes a status code (eg: “404 - Not Found”, “200 - Okay”, or “500 - Server Error”) and a payload (usually text or JSON data). This response format should also be specified in the documentation of the API so that developers know what to expect when they make a successful request.
Types of API
Open APIs - Also known as Public APIs. These APIs are publicly available and there are no restrictions to access them.
Partner APIs - These APIs are not publicly available, so you need specific rights or licenses to access them.
Internal APIs - Internal or private. These APIs are developed by companies to use in their internal systems. It helps you to enhance the productivity of your teams.
Composite APIs - This type of API combines different data and service APIs.
SOAP - It defines messages in XML format used by web aplications to comunicate with each other.
REST - It makes use of HTTP to GET, POST, PUT or DELETE data. It is basically used to take advantage of the existing data.
JSON-RPC - It uses JSON for data transfer and is a light-weight remote procedural call defining few data structure types.
XML-RPC - It is based on XML and uses HTTP for data transfer. This API is widely used to exchange information between two or more networks.
Features of API
It offers a valuable service (data, function, audience).
It helps you to planabusiness model.
Simple, flexible, quickly adopted.
Managed and measured.
Offers great developer support.
Examples of API
Razorpay API
Google Maps API
Spotify API
Twitter API
Weather API
PayPal API
PayTm API
HubSpot API
Youtube API
Amazon's API
Travel Booking API
Stock Chart API
API Testing Tools
Postman - Postman is a plugin in Google Chrome, and it can be used for testing API services. It is a powerful HTTP client to check web services. For manual or exploratory testing, Postman is a
good choice for testing API.
Ping API - Ping API is API testing tool which allows us to write test script in JavaScript and CoffeeScript to test your APIs. It will enable inspecting the HTTP API call with a complete request and
response data.
VREST - VREST API tool provides an online solution for automated
testing, mocking, automatic recording and specification of
REST/HTTP APIS/RESTful APIs.
When to create an API and when not to
Its very important to remember when to create and when not to create an API. Let’s start with when to create an API…
You want to build a mobile app or desktop app someday
You want to use modern front-end frameworks like React or Angular
You have a data-heavy website that you need to run quickly and load data without a complete refresh
You want to access the same data in many different places or ways (eg: an internal dashboard and a customer-facing web app)
You want to allow customers or partners limited or complete access to your data
You want to upsell your customers on direct API access
Now, when not to create an API…
You just need a landing page or blog as a website
Your application is temporary and not intended to grow or change much
You never intend on expanding to other platforms (eg: mobile, desktop)
You don’t understand the technical implications of building one.
Please don’t wait for people to spoon-feed you with every single resource and teachings because you’re on your own in your learning path. So be wise and learn yourself.
Check out my book
I have curated a step by step guideline not just for beginners but also for someone who wants to come back and rebrush the skills. You will get to know from installing necessary tools, writing your first line of code, building your first website, deploy it online and more advanced concepts. Not only that, I also provided many online resources which are seriously spot on to master your way through. Grab your copy now from here. Or you can get it from this link below.
Dive into the dynamic and ever-evolving world of web development with this comprehensive guide, perfect for both beginners eager to learn an
About Me
I am Ishraq Haider Chowdhury from Bangladesh, currently living in Bamberg, Germany. I am a fullstack developer mainly focusing on MERN Stack applications with JavaScript and TypeScript. I have been in this industry for about 11 years and still counting. If you want to find me, here are some of my social links....
While experimenting with Tailwind CSS and OpenAI chat basics, I realized there's still a lot for me to learn about Tailwind CSS.
I would need to understand the following concepts and theories:
JavaScript (ES6+): The code is written in JavaScript, specifically using ES6 syntax and beyond. You should be familiar with concepts such as import/export statements, async/await syntax for handling promises, arrow functions, and more.
React and JSX: The index.jsx file uses React, a JavaScript library for building user interfaces. You should understand how to create functional components, manage state with hooks like useState and useRef, and write JSX.
Node.js and Server-Side JavaScript: The chat.js file is a server-side JavaScript file. You should understand how to write and export server-side functions, handle HTTP requests and responses, and work with modules.
OpenAI API: The code uses the OpenAI API to generate chat responses. You should understand how to interact with APIs, specifically how to send requests and handle responses.
Fetch API: The fetch function is used to make HTTP requests from the client-side code. You should understand how to use it to send GET requests and handle the responses.
Astro: The project is built with Astro, a front-end framework. You should understand how to set up an Astro project, write Astro components, and use Astro's build commands.
npm and package.json: The package.json file is used to manage the project's dependencies and scripts. You should understand how to use npm to install packages, and how to define and run scripts in package.json.
Markdown: The README.md file is written in Markdown, a lightweight markup language. You should understand how to write Markdown to create formatted text.
Understanding of HTTP methods and RESTful APIs: The GET function in chat.js is a clear indication that you need to understand how HTTP methods work, particularly GET. Understanding how to design and work with RESTful APIs would be beneficial.
Understanding of JSON: JSON is used extensively for data interchange in this code. You should understand how to create, parse, and work with JSON data.
a study plan for JavaScript (ES6+), React, and JSX that should give me enough knowledge to write the code I want:
Week 1-2: JavaScript (ES6+)
Day 1-3: Basics of JavaScript: variables, data types, operators, control structures (if-else, switch, loops), functions, arrays, and objects.
Day 4-5: Advanced JavaScript: closures, this keyword, prototype, and object-oriented JavaScript.
in JavaScript, you can create an object consisting of key-value pairs with the following syntax:
const someObject = { 'foo': true, 'bar': false };
if you're familiar with any other programming languages, you might call this structure a dictionary, and think of it as it's own type compared to (for example) an array or a set.
but in JS, everything except the built-in primitives are objects:
what's the clearest way to communicate that I am specifically talking about an object that consists of just key-value pairs, and not another, fancier kind of object?
JS devs: what do you call it?
Just "object"
"Plain object"
"Dictionary"
"Record"
Something else (put it in the replies!)
Voting ended onMar 6, 2023
Bonus: what I think your answer says about you...
Just "object": you might think it's silly that most things in JS are objects, or at the very least, you think it's silly to acknowledge it unless it's the subject matter of the conversation. You're comfortable allowing omission of words to communicate your meaning.
"Plain object": you don't want to be misinterpreted, but you're either a stickler for using JS-specific language when talking about JS, or want to avoid your words being nitpicked by colleagues who are.
"Dictionary": you're seasoned enough another programming languages that this is just your default way refer to this data structure, regardless of the situation.
"Record": you live and breath TypeScript. There's a good chance you even prefer to specify the types of the values, i.e. "Record".
So I'm switching out the architecture of my game to an Entity Component System, and I was using a library called Pico Ecs which is an stb style single header library.
But after using it for literally a morning there were inconsistencies and bugs popping up. And I've programmed enough to see where this is going.
So I started work on my own ecs, which in c can be done with some function pointers and the right data structure.
Which in this case is a Sparse Set, which I'm still wrapping my brain around. But all I know is that data is stored in a densely packed array, and the indices for the data you want is stored in a sparsely packed array.
Also you are limited to arrays, no linked lists or anything. And there are only a handful of instances a sparse data set can be used for do to its strict typing.
But the positive with sparse sets is, adding, deleting, and SEARCHING are all O(1) time. Which means no matter how many items are in the dataset it takes the same ammount of time to access it.
Basically its perfect for entity component systems.
I wanna make a video breaking it down once I finish it so stay tuned.
17. What's a programming/tech thing you feel very strongly about?
The decision to use Javascript to build applications is the single worst idea to ever be thought in computer science. Even worse than OOP.
I used to think "oh I dont know javascript super well maybe it's not so bad". After learning javascript inside and out, it is truly the most poorly designed piece of shit language to ever be created. It seems to challenge itself to come up with the most abstract absurd solutions to problems that could be solved with a single function. If the guy tasked with making the language spent a little more than 10 days designing it we as a sphere of engineering would have saved millions of hours of programming hours and billions of dollars in wasted cpu cycles.
Javascript is fine for powering buttons and login forms. But the fact that Visual Studio Code is written in Javascript is such a bafflingly stupid decision I'm unsure if the words exist to describe it.
