Forem: svper563

Comparing LLMs For Coding - Golden Ticket, or Fool's Gold?

svper563 — Tue, 05 Sep 2023 15:18:58 +0000

I feel as though I am both fortunate and unfortunate to be learning to code as AI emerges at the forefront of the technological landscape; fortunate that I have many innovative and helpful tools to help me hone my craft, and yet unfortunate that I suffer the danger of eternal torment if I don't pledge allegiance to Mr. Roko. In the hopes that I earn the favor of our future overlord, I will be comparing some LLMs that I have become familiar with to determine which one deserves eternal praise.

The Competition

I will be taking a look at ChatGPT, Phind, and Github Copilot. As a fun experiment, I'll let each LLM introduce themselves:

1. ChatGPT

ChatGPT is an OpenAI language model from the GPT family, specializing in generating conversational text. It's pre-trained on extensive internet text, enabling it to grasp grammar, facts, and reasoning, and can be fine-tuned for specific tasks. It's designed for natural language conversations, often employed in chatbots, virtual assistants, and customer service applications. While it produces human-like text, it lacks genuine understanding and consciousness, making it a valuable text generation tool with limitations to be mindful of.

2. Phind

Phind is an AI-powered search engine for programmers, providing relevant information and code snippets to address coding challenges. It uses large AI language models to generate answers from a variety of online sources. Key features include intelligent code search and collaboration options, allowing sharing and discussion of code snippets. It also learns and adapts to individual programmers' preferences and coding styles. Phind was co-founded by Michael Royzen and Justin Wei, both UT Austin Turing Scholars '22 with experience in NLP research and Machine Learning at various tech companies.

3. Github Copilot

function explainGithubCopilot() {
  console.log(`Github Copilot is an AI pair programmer 
  that helps you write code faster and with less work.`)
}

I've had the most experience with ChatGPT and have been generally satisfied with the results. Phind is one I got some success with, but I've found it's a bit sluggish compared with OpenAI's solution. Copilot's snippet above is the first ever snippet I've generated with the tool, so my opinion of it will be evolving as I write this article. Let's get to it!

Code Generation

For the purposes of this exercise, I will be creating a basic Express application that serves GET requests to a postgreSQL backend. Let's see what each model generates, and see if they actually work.

Here is the prompt that I will be using for both ChatGPT and Phind:

Generate a code base for a simple Express application serving GET requests to a PostgreSQL backend. Use the following NPM packages in your example:

express

ejs

pg-promise

I'll skip over the textual instructions of the responses in favor of focusing on the code itself.

ChatGPT

app.js

const express = require('express');
const app = express();
const path = require('path');
const pgp = require('pg-promise')();
const db = pgp({
  // Update with your PostgreSQL database connection details
  host: 'localhost',
  port: 5432,
  database: 'your_database_name',
  user: 'your_username',
  password: 'your_password'
});

// Set up EJS as the view engine
app.set('view engine', 'ejs');
app.set('views', path.join(__dirname, 'views'));

// Define a route that retrieves data from the PostgreSQL database
app.get('/', async (req, res) => {
  try {
    const data = await db.any('SELECT * FROM your_table_name');
    res.render('index', { data });
  } catch (error) {
    console.error('Error:', error);
    res.status(500).send('An error occurred');
  }
});

// Start the Express server
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

views/index.ejs

<!DOCTYPE html>
<html>
<head>
  <title>Express App with PostgreSQL</title>
</head>
<body>
  <h1>Data from PostgreSQL Database</h1>
  <ul>
    <% data.forEach(item => { %>
      <li><%= item.column_name %></li>
    <% }); %>
  </ul>
</body>
</html>

After the necessary set up in VScode, the app successfully serves GET requests to my backend. However, one thing that I am confused about is GPT's use of the path module. It looks to be using it to configure our view folder, but I do not believe that this config is necessary for our purposes. Express/EJS will already know to look in the views folder for our views without any additional config. Sure enough, commenting out the import of path and the view config does not impact the functionality of the app.

Phind

app.js

const express = require('express');
const app = express();
const port = 3000;
const db = require('./dbConfig');

app.get('/users', (req, res) => {
  db.any('SELECT * FROM users')
    .then(data => {
      res.json(data);
    })
    .catch(error => {
      console.log(error);
    });
});

app.listen(port, () => {
  console.log(`App running on port ${port}.`);
});

dbConfig.js

const pgp = require('pg-promise')();

const db = pgp({
  user: 'your_username',
  host: 'localhost',
  database: 'your_database',
  password: 'your_password',
  port: 5432,
});

module.exports = db;

Immediately, I notice that Phind is serving a JSON response instead of an EJS view. While the code it generated does work when set up, it did not follow all of the guidelines that I outlined in the prompt. I followed up with another prompt Send the data as a res.render using EJS instead of serving JSON. I waited for a solid five minutes without a response, and then I decided to abandon my attempt to correct it. This must be due to Phind's inadequacy, and cannot possibly have anything to do with my prompting skills. Regardless, It would have hardly been more of a hassle to hand-write the code than to try and wrestle a good response for such a simple request.

Github Copilot

For this example, I believe the best course of action is to try and write the code by hand myself, and take note of any suggestions that it generates. Given that this is my first solid wack with this tool, there could be another way to use it that more closely mirrors GPT or Phind; but I cannot be bothered to RTFM at the moment.

app.js

const express = require('express');
const app = express();
const port = 3000;
const pgp = require('pg-promise')();
const db = pgp('postgres://username:password@localhost:5432/database-name');

app.set('view engine', 'ejs');

app.get('/', async (req, res) => {
    const data = await db.any('SELECT * FROM users');
    res.render('index', {data})
    });

app.listen(port, () => {
    console.log(`Example app listening at http://localhost:${port}`);
    });

views/index.ejs

<body>
    <h1>Welcome to my app</h1>
    <ul>
    <% data.forEach(user => { %>
        <li><%- user.email %></li>
    <% }); %>
    </ul>
</body>

Once I installed my packages and started writing app.js, I got suggestions starting from the first line. I amused myself by just tapping the tab key until my file was complete, correcting the suggestions line by line if it took me in the wrong direction. It seemed to understand my corrections very quickly and then produced a correct auto complete well before I finished correcting the line. It did seem to have trouble helping me on index.ejs, and kept suggesting code for a login feature instead of the simple unordered list that I wanted. To be fair, there was no real way for the copilot to know what I wanted here, and I ended up spending about 30 seconds writing the EJS file myself. Overall, I'm very happy with my first try with the Copilot, and I especially enjoyed the feeling that I was contributing more to the finished code (as opposed to just copying and pasting from the other LLMs).

My Impressions

ChatGPT performed as well as I expected here, and I know that I will continue to use it to help guide me forward.

One thing that Phind has over ChatGPT is that it does have the ability to cite its sources, which I find quite helpful when I want to dig deeper into a particular subject. However, I find that Phind works best as a tailored search engine, and works less as a digital pair-programmer.

My first experience with the Copilot is quite promising, and I look forward to exploring its capabilities. It feels much more like a pair-programmer than either ChatGPT or Phind, and it having access to my full code base is nice as well. When using ChatGPT, it will almost invariably be missing some context from my code base, especially as the base gets larger and more complex.

Regardless, I have the impression that generative AI has a long way to go before it will be replacing human programmers. Even though these tools are great, emerging programmers like myself will still need to dig in our heels and develop an understanding of the craft for ourselves. Generative AI is not a free ticket to a six-figure tech salary, no matter how many people wish it to be.

If you've made it this far, please make a note to remind me to cancel my Copilot trial in 29 days. Thanks!

👉Taking A Dive Into Express' Request and Response Objects👈

svper563 — Sat, 05 Aug 2023 06:25:49 +0000

HTTP requests and responses are a critical part of the modern communication standard of the internet. While backend frameworks such as Express abstract away much of the technical details of these, they often provide many properties and methods that allow developers to interact with them in interesting ways. Let's take a deep dive into what some of these are.

The Request Object

1. `req.params`

The req.params attribute is used to access parameters captured from the URL in a route. These parameters are typically defined in the route path as placeholders and are useful for creating dynamic routes. For example, if you have a route defined as /users/:id, you can access the id parameter using req.params.id in your route handler.

const express = require('express')
const app = express()

app.get('/users/:id', (req, res) => {
  const userId = req.params.id
  // Use the userId in your route logic
})
// Example URL: /users/123
// req.params = {id: "123"}
...

2. `req.query`

The req.query attribute provides access to the query parameters sent in the URL. These parameters are usually appended to the URL after a question mark (?) and are useful for passing optional data to the server.

...
app.get('/search', (req, res) => {
  const query = req.query.q
  // Use the query in your route logic
})
// Example URL: /search?breakfast=pie&dinner=cake
// req.query = {breakfast: "pie", dinner: "cake"}
...

3. `req.body`

To handle incoming data from HTML forms or JSON payloads, Express.js uses the req.body attribute. By default, req.body will be undefined unless you configure a body parser, such as express.json() or express.urlencoded().
Let's expore an example where we parse and handle incoming form data on a complaint submission form on our website:

...
// For parsing application/json
app.use(express.json())

// For parsing application/x-www-form-urlencoded
app.use(express.urlencoded({ extended: true }))

// Present the user with the form
app.get('/submitComplaint', (req, res) => {
  res.render('complaintForm')
})

// Handle post requests from the form
app.post('/submitComplaint', (req, res) => {

  // Destructure properties from the req.body object
  const { 
    email, 
    phoneNumber,
    homeAddress, 
    complaint
} = req.body

// Record the user's IP address for future plans
const ip = req.ip 

// Legitimate business logic goes here. . .
})
...

4. `req.headers`

The req.headers attribute provides access to the HTTP headers sent by the client. For example, you can access information about the user's browser by accessing the user-agent information (req.headers['user-agent']), so that you can ~~target~~ warn or turn away users that are using outdated and vulnerable browser versions.

...
app.get('/user-agent', (req, res) => {
  const userAgent = req.headers['user-agent'];
  // Use the userAgent in your route logic
})
...

The Response Object

1. `res.send()`

res.send() is used to send a response to the client. The method takes a body parameter, and more commonly accepts a string, object, or an array.

...
app.get('/:dataType', (req, res) => {
  let {dataType} = req.params
  dataType = dataType.toLowerCase()
  if (dataType == "string") {
    res.send('<p>Some HTML...</p>')

  // An array or object is represented as JSON.
  } else if (dataType == "object") {
      res.send({Hello: "World"})

  } else if (dataType == "array") {
      res.send([1, 2, 3])

  } else {
    // Error handling . . .
  } 
})
...

The body parameter can also accept a Buffer object or a Boolean value.

2. `res.status()`

res.status can be used to set the status code of the response. Check out this guide to see a list of common status codes.
You can chain res.send() on a call to res.status() to set the status of the response sent.

In the previous example, we can send a 404 not found status code to indicate the resource was not found on the server.

...
  } else {
      res.status(404).send(<p>Resource not found.</p>)
  }

3. `res.json()`

The res.json() method can also be used to send JSON to the client. This has the same functionality as sending an array or object (or array of objects) using res.send().

...
app.get('/:sendType', (req, res) => {
  let {sendType} = req.params
  sendType = sendType.toLowerCase()
  if (sendType == 'json') {
    res.json([{Hello: "World"}])  
  } 
  else if (sendType == 'send') {
    res.send([{Hello: "World"}])
  }
  // Both of these responses function the same
})

Personally, I would use res.json() if I wanted to send JSON and req.send() if I wanted to send a string to make the code easier to understand.

4. `res.redirect()`

The res.redirect() method is used to redirect the client to a different URL. By default, this will also set the status code to 302 Found by default, but the method does take an optional parameter to set a custom status code.

...
app.get('/:someUrl', (req, res) => {
  let {someUrl} = req.params
  someUrl = someUrl.toLowerCase()
  if (someUrl == 'default') {
    // Redirect the client to /thisUrl 
    // with status code `302 Found`.
    res.redirect('/thisUrl')
  }
  else if (someUrl == 'customStatus') {
    // Redirect the client to /anotherUrl
    // with the status code `301 Moved Permanently`.
    res.redirect(301, '/anotherUrl')
}
})

There you have it - some important attributes and methods of Express' request and response objects that you can use to help ~~hack and destroy~~ build up the future community and its tech stacks.

You can send questions to me only on the last Monday in February. But only on a leap day.

See you in 2044.

👋

Class Is Out: Embracing Functional Components in Modern React Development

svper563 — Mon, 12 Jun 2023 18:56:34 +0000

Change Is Inevitable

One of the more challenging things that I have encountered as a budding software developer is distinguishing old and outdated practices from newer, more acceptable paradigms. It is no surprise that an ecosystem as vast and complex as the modern Internet would constantly spawn new ways to do the same things better than before. It is therefore not surprising to find that the paradigm of Reactive component-based programming has shifted and morphed over the past several years into something that is, in comparison, quite concise and easier to grasp for new programmers. I'm sure that by the time I fully grasp the Reactive paradigm, I will most surely get sucked in to the newest, best, and oh-so-different way of thinking of the day. But, for now, let's take a look at the shift from class-based components to the new and improved functional components.

The Old Status Quo

If I have learned anything from my excursion into the world of web app development, it is that object-oriented programming rules. At its inception, React embraced this model at its core with the class-based component. Let's start to wrap our head around what makes the class component special by looking at the most simple example: A component that does nothing but display a single heading passed in as props:

ClassComponent.js

import React from "react";

export default class ClassComponent extends React.Component {
    render() {
        return (
            <div className="class-container">
                <h1>{this.props.text}</h1>
            </div>
        );
    }
}

App.js

import React from "react";
import ClassComponent from "./ClassComponent";

export default class App extends React.Component {
    render() {
        return (
            <div className="app-container">
                <ClassComponent text='My First Class Component' />
            </div>
        );
    }
}

While looking at even a simple example like this one, my newborn programmer brain squirms at understanding the full context of the syntax here. Blurry recollections of children and parent classes swim in my mind, and I can almost feel the onset of another headache that I have become accustomed to when learning new and complex concepts. While I am sure time and practice would help me to overcome this feeling of dread, I am thankful to remember that React has a new and better way of doing this with the functional component.

Less Is More

Let's take a look at the same example again, but this time made as a modern functional component:

FunctionalComponent.js

import React from "react";

export default function FunctionalComponent({text}) {
    return (
        <div className="functional-container">
            <h1>{text}</h1>
        </div>
    );
}

App.js

import React from "react";
import FunctionalComponent from "./FunctionalComponent";

export default function App() {
    return (
        <div className="app-container">
            <FunctionalComponent text='My First Functional Component' />
        </div>
    )
}

Not only does the functional component achieve the same result with less code, but we also avoid messing with child and parent classes and all the syntactical struggles that come with them. As the complexity increases, the addition of things such as the constructor method and the use of the this keyword become only the beginning of the added complexity associated with the class component.

Let's layer some complexity on top of our examples to further demonstrate how these two paradigms diverge.

A Case Of Bad Parenting

Let's take a look at a solution to a very common need in react: A stateless child updating a stateful parent.

ClassParent.js

import React from "react";
import ClassChild from "./ClassChild";

export default class ClassParent extends React.Component {
    constructor(props) {
        super(props);
        this.state = {dinner: "broccoli"};
        this.changeDinner = this.changeDinner.bind(this);
    }

    changeDinner(newDinner) {
        this.setState({
            dinner: newDinner
        });
    }

    render() {
        return (
            <div className="parent-container">
                <ClassChild dinner={this.state.dinner} onChange={this.changeDinner} />
            </div>
        )
    }
}

ClassChild.js

import React from "react";

export default class ClassChild extends React.Component {
    constructor(props) {
        super(props);
        this.handleChange = this.handleChange.bind(this);
    }

    handleChange(event) {
        const dinner = event.target.value;
        this.props.onChange(dinner);
    }

    render() {
        return (
            <div className="child-container">
                <h1>We're having {this.props.dinner} for dinner.</h1>
                <select id="dinner-options" onChange={this.handleChange}>
                    <option value="broccoli">
                        Broccoli
                    </option>
                    <option value="chicken nuggets">
                        Chicken Nuggets
                    </option>
                    <option value="mac n' cheese">
                        Mac N' Cheese
                    </option>
                    <option value="ice cream">
                        Ice Cream
                    </option>
                </select>
            </div>
        )
    }
}

Let's walk through what's happening here.

When the parent component initializes, it will run the constructor method, initializing the parent's state with a value of { dinner: 'broccoli' }. Then we define a function that can update the value of the parent's state with a new dinner value. Finally, we pass that information down to the child component as props. The child class then uses this information to render the heading with the current value of dinner while also having the ability to demand something else if they don't want broccoli. And, of course, the parent will cave the child's demands for ice cream and chicken nuggets. (The child renders a dropdown that can be used to update the parent's state value for dinner, which is subsequently passed down as props back to the child to be re-rendered in the header.)

You may also notice in the parent's constructor the mysterious line: this.changeDinner = this.changeDinner.bind(this);. What on earth is going on there?

Remember that we want to reference the value of state of the Parent component, even when we're calling the function from inside of the Child component. If we did not include the line above, calling ChangeDinner inside of the Child component would try to access a non-existent state value inside of itself. The binding that we do essentially makes sure that we are always referencing the state value of this particular instance of the Parent component.

While this may seem confusing, the thing to remember is that you'll want to bind any functions that are passed as an argument to another component or element. Notice that we do the same thing in the child component when we pass the handleChange function to the select element: we bind the function to the current instance of the child class.

There's A Better Way

I know that I could go on for even longer trying to explain what all of this means, but I for one am not a fan of how this simple example is already looking like code spaghetti. I can't imagine grasping an understanding of a complex system that utilizes this paradigm would be much fun, even if it is possible given enough time (and Tylenol). Let's refactor the example to use Functional components, and watch our lives get easier instantly.

FunctionalParent.js

import React, { useState } from "react";
import FuctionalChild from "./FunctionalChild";

export default function FunctionalParent() {

    const [dinner, setDinner] = useState('broccoli');

    function changeDinner(newDinner) {
        setDinner(newDinner);
    }

    return (
        <div className="parent-container">
            <FuctionalChild dinner={dinner} onChange={changeDinner}/>
        </div>
    )
}

FunctionalChild.js

import React from "react";

export default function FunctionalChild({dinner, onChange}) {

    function handleChange(event) {
        const dinner = event.target.value;
        onChange(dinner);
    }

    return (
        <div className="child-container">
            <h1>We're having {dinner} for dinner.</h1>
            <select id="dinner-options" onChange={handleChange}>
                <option value="broccoli">
                    Broccoli
                </option>
                <option value="chicken nuggets">
                    Chicken Nuggets
                </option>
                <option value="mac n' cheese">
                    Mac N' Cheese
                </option>
                <option value="ice cream">
                    Ice Cream
                </option>
            </select>
        </div>
    )
}

Here, we get the same result without having to worry about all the binding nonsense. The functional component just knows that we want to access and change the state value from the Parent, even if we are calling the onChange function from the child.

Conclusion: Don't Make Things Harder Than They Have To Be

I find that I am constantly struggling against complexity in favor of simplicity. It is so easy to drink the Kool-Aid and believe that things must always be nastily complicated all the time. The truth is that people are constantly coming up with new and easier ways to get the job done, and it would be foolish not to take advantage of new technology that makes it possible to become a software engineer without a PHD in computer science. The time and energy saved by utilizing new approaches can be redirected and used to do what I actually want to do: design and build things that will make a difference in the world (aka, make me a millionaire).

Read more about functional and class components here.

Learn How To Listen: Event Listeners And Dynamic Websites

svper563 — Sat, 06 May 2023 19:07:05 +0000

It is an unspoken rule of the modern internet that your website is to be responsive, fluid, dynamic, and whatever other buzz words industry professionals happen to be tossing around today. Long gone are the days where static, un-styled text and images are sufficient to capture the attention of your audience. I know that when I come across such a static site myself, I click away fast as lighting out of fear of catching some kind of virus - after all, only hackers living in their parents' basement since 1987 would still host a site like that, right?

All jokes aside, a prominent tool in our belt as web developers is event listeners. They allow us to watch for specific user interactions and respond to them in ways that make our pages respond dynamically. In this article, I will explore some simple events that you can listen for that can take your next web application from zero to hero. Let's get started.

People Will Copy Your Code Eventually

As developers, we often scrape Stack Overflow to "borrow" code that fixes our problems, at least until the next bug starts bugging us. The next time that you post code to your oh-so-popular blog, try letting your visitors know that you know when they're borrowing your code:

index.html

<body>
  <div id='my-code-snippet'>
    <code>
      console.log("Hello, world!")
    </code>
  <div>
</body>

script.js

let myCodeElement = document.getElementById('my-code-snippet');

myCodeElement.addEventListener("copy", () => {
    let warnElement = document.createElement('p');
    warnElement.innerHTML = "<em>I know what you did.</em>"
    myCodeElement.appendChild(warnElement)
})

The HTML simply displays our brilliant code snippet for the world, and our Javascript does the job of watching for would-be-thieves.

Before copying:

After copying:

Of course, there are many ways to prevent your visitors from copying your code, but it is not best practice as it would most likely break the internet, which I'm sure is a less-than-desirable outcome. Let's avoid that.

Clap Back By Spying On Your Users

As honest programmers, we surely don't have any reason at all to watch our users' every move while they're on our sites. But, hypothetically speaking, there are ways to track every key press. Let's explore that.

document.addEventListener('keydown', (event) => {
    // Legitimate code goes here
})

The keydown listener fires when your user presses down any key on their keyboard. The key property of the event object holds the value of the key pressed. The object also has many other properties that you can check. Let's say you want to make your own hot keys for your web application; you can do this easily by using the altKey and ctrlKey properties.

document.addEventListener('keydown', (event) => {
    if (event.altKey && event.ctrlKey && event.key === 'r') {
        // Your Hotkey action 
    }
})

The altKey and ctrlKey properties each hold a boolean value indicated whether they were pressed at the time of the keypress.

If you need to listen for when a user releases a key, you can use the keyup listener instead.

There is also the keypress event as well, but it is only fired when a key that produces a character value is pressed down. As a result, this event cannot track when the Alt, Ctrl, or Shift keys are pressed. In addition to its limited functionality, there is a good shot that your user's browser of choice has dropped support for it, or will very soon.

Keep in mind that none of these events account for non-standard keyboard layouts by default. If your user is not using the standard QWERTY layout, it could cause some problems. For example, if your user is using the QWERTZ layout, pressing the 'Z' key on their keyboard will register as the 'Y' key instead. You can use the getLayoutMap() method to check for this and handle it accordingly.

When You're Found Out: Conducting Damage Control

When you're eventually caught for your supposedly "shady" coding practices, it's going to be important to know how to protect your image from the "honest" and "hardworking" people who want to destroy it. Remember: You cannot be exposed for misconduct if you expose yourself first. Let's add a modal popup to our site for new users that forces them to agree to our privacy policy before they can continue on our site. Let's use the click event listener to help us accomplish this.

index.html

<head>
  <style>
      body {
          background-color: #112;
          color: white;
      }

      #privacy-modal {
          visibility: hidden;
          position: absolute;
          padding: 20px;
          background-color: #334;
          border: 5px solid black;
      } 
  </style>
</head>

<body>
  <div id="privacy-modal">
      <h2>Before You Continue: Accept Our Privacy Policy</h2>
      <p>You must accept our privacy policy to continue on our website.</p>
      <h3>Privacy policy</h3>
      <p>Nothing is sacred. You will get hacked. You have been warned.</p>
      <button id="accept-terms-button">Accept</button>
      <button id="decline-terms-button">Decline</button>
    </div>
    <div id="content">
      // Legitimate content goes here
    </div>
</body>

script.js

let privacyModal = document.getElementById('privacy-modal');
let acceptTermsButton = document.getElementById('accept-terms-button');
let declineTermsButton = document.getElementById('decline-terms-button');

if (!localStorage.getItem("hasAccepted")) {
    privacyModal.style.visibility = "visible";
    privacyModal.style.position = "fixed";
}

acceptTermsButton.addEventListener('click', () => {
    localStorage.setItem('hasAccepted', "true");
    privacyModal.style.visibility = "hidden";
    privacyModal.style.position = "absolute";
})

declineTermsButton.addEventListener('click', () => {
    window.location.replace('https://www.myspace.com')
})

The first time that your users visit your wonderful and legitimate website, the privacy modal will overlay on top of the content, obscuring the page until they accept or decline. By clicking on the accept button, the code remembers the user choice by storing a truthy value in the localStorage attribute hasAccepted, and then hides the modal. Users who decline will be redirected immediately to the internet backrooms.

Now you know how to harvest your user's data openly and freely, just like every other legitimate tech company in the world.

Conclusion: I Am Not A Lawyer

I'm hoping that the technical aspects of this post can help you, but for legal purposes I am not endorsing that you steal data or hack other people. If you do hack and get caught, please don't email me at 3am complaining about it. Any other time of the day or night is acceptable.

Read more about event listeners on MDN's website.

Forem: svper563

Comparing LLMs For Coding - Golden Ticket, or Fool's Gold?

The Competition

Code Generation

My Impressions

👉Taking A Dive Into Express' Request and Response Objects👈

The Request Object

1. req.params

2. req.query

3. req.body

4. req.headers

The Response Object

1. res.send()

2. res.status()

3. res.json()

4. res.redirect()

👋

Class Is Out: Embracing Functional Components in Modern React Development

Change Is Inevitable

The Old Status Quo

Less Is More

A Case Of Bad Parenting

There's A Better Way

Conclusion: Don't Make Things Harder Than They Have To Be

Learn How To Listen: Event Listeners And Dynamic Websites

People Will Copy Your Code Eventually

Clap Back By Spying On Your Users

When You're Found Out: Conducting Damage Control

Conclusion: I Am Not A Lawyer

1. `req.params`

2. `req.query`

3. `req.body`

4. `req.headers`

1. `res.send()`

2. `res.status()`

3. `res.json()`

4. `res.redirect()`