DEV Community: Quave

Building Reactive Lists with Meteor and Blaze

Mateus Ragazzi — Tue, 23 Sep 2025 14:42:20 +0000

Hey there! If you're diving into building real-time apps, you know how crucial it is to keep your UI up-to-date. At Quave, we're big fans of Meteor JS and its ecosystem to make this happen.

One of available tools is Blaze JS, which gives you a great platform for creating real-time apps. While Blaze isn't recommended for new projects (the Meteor team now focuses on React and Vue.js), you'll likely encounter it in legacy codebases.

Today, I'm gonna walk you through how to build a reliable and reactive list using Blaze's #let directive. Trust me, this will save you from some async nightmares when working with existing Blaze applications!

The Problem with Lists

Lists are everywhere in apps — user lists, task lists, etc. Keeping them updated in real-time when data changes can be tricky sometimes. You might be tempted to use a ReactiveVar to manage your list's state, and that's not a bad idea. But Blaze's #let directive can make your life way easier by simplifying how you handle reactive data sources. Let's see how it works.

Reactive List with `#let`

Imagine you've got a list of users you want to display, and it needs to update instantly when a new user is added or one gets updated. Instead of using ReactiveVar or dealing with async and sync operations, Blaze's #let lets you declaratively bind a reactive data source to a variable in your template.

To achieve that, you need to set up a helper in your JavaScript to fetch the data reactively. For our user list, we'll use Meteor's Users collection and sort it by creation date:

Template.myTemplate.helpers({
  myList() {
    return Users.find({}, { sort: { createdAt: -1 } }).fetch();
  }
});

This helper gets all users from the Users collection, sorted by the most recent first. The fetch() method ensures we get an array of documents that Blaze can work with.

Now, in your Blaze template, you use the #let directive to bind this helper to a variable called list. Then, you can iterate over it or check its length to display the right UI:

<template name="myTemplate">
  {{#let list=myList}}
    {{#if list.length}}
      <ul>
        {{#each user in list}}
          <li>{{user.name}}</li>
        {{/each}}
      </ul>
    {{else}}
      <p>No users found.</p>
    {{/if}}
  {{/let}}
</template>

Here's what's cool about this setup:

Since myList is backed by a Meteor find query, it's reactive. If a new user is added to the Users collection, the list updates automatically, and Blaze re-renders the UI.
The #let directive lets you assign the helper's result to a variable (list) that you can use throughout the template. It keeps your code readable and avoids messy nested helper calls.
By using list.length, you can easily toggle between showing the list or a "No users found" message, avoiding using a helper to do so.

Should I use `#let` or `ReactiveVar`?

The choice between #let with reactive helpers and ReactiveVar often comes down to your specific use case: #let excels for straightforward data binding from collections, while ReactiveVar shines when you need to manage derived state or implement custom reactive logic that doesn't directly map to a database query.

Wrapping Up

Building reactive lists doesn't have to be a nightmare, specially on legay code bases. With Meteor and Blaze's #let directive, you can create real-time UIs with minimal code.

Got questions or want to share your own Meteor tips? Drop a comment below, and let's keep the conversation going!

Understanding Lighthouse: The Metrics That Actually Matter for Performance and SEO

Guilherme Araujo — Thu, 10 Jul 2025 12:52:43 +0000

🔍 What Is Lighthouse?

Lighthouse is an automated tool that audits web pages and generates a report about five main categories:

Performance;
Accessibility;
Best Practices;
SEO;
Progressive Web App (PWA).

For example, here's the Lighthouse report for dev.to's main page:

The report gives each category a score, along with helpful suggestions for improvement. Here, we’ll focus mainly on the Performance category — the one that impacts users the most, and is often the most important when it comes to SEO and UX.

Performance

The Performance score in Lighthouse is based on a set of real-world metrics, many of which are part of Google’s Core Web Vitals. These metrics measure how your site loads and responds from the user’s point of view.

Let’s break them down:

First Contentful Paint (FCP)

Measures how long it takes for the first piece of content to show up on the screen, like text or an image. It gives users feedback that something is happening.

Largest Contentful Paint (LCP)

Tells you how long it takes for the main piece of content to load, usually a large image or headline. It shows when the page becomes useful.

Speed Index

Tracks how quickly visible parts of the page appear during loading. Lower scores mean faster and smoother loading.

Time to Interactive (TTI)

Measures how long the page takes to become fully usable. In summary, when a user can click or type without delays.

Total Blocking Time (TBT)

Adds up how much time the browser is “too busy” to respond to user input, often due to heavy JavaScript tasks.

Cumulative Layout Shift (CLS)

Tracks unexpected layout changes, like when content moves while the page is still loading. This helps prevent those annoying jumps that make users click the wrong thing.

How Are Lighthouse Scores Calculated?

Not all metrics count the same toward the final performance score. Metrics like LCP and TBT have more weight because they directly affect how smooth the site feels to real users.

Lighthouse uses real-world data from tools like the HTTP Archive and Chrome UX Report to compare your site with others on the web.

Here’s the current weight breakdown:

Largest Contentful Paint (LCP): 25%
Total Blocking Time (TBT): 30%
Cumulative Layout Shift (CLS): 15%
First Contentful Paint (FCP): 10%
Speed Index: 10%
Time to Interactive (TTI): 10%

What About the Other Categories?

Performance is super important, but the other Lighthouse categories also matter:

Accessibility checks if your site works well for people with disabilities.

Best Practices makes sure you’re following web and security standards.

SEO looks at basic on-page SEO, like titles, meta tags, and headings.

PWA checks if your site can work like an app on mobile devices.

These don’t directly affect Core Web Vitals, but they’re key for overall user experience.

🚀 How to Improve Your Scores

Improving your Lighthouse performance score doesn't mean rewriting your entire site, many optimizations are small tweaks that can have a big impact. Let’s dive deeper into the most effective techniques and how they help your metrics.

Optimize Images

Images often make up the bulk of a page’s weight. If they’re not optimized, they can slow down your site dramatically.

Use modern formats like WebP or AVIF: These formats offer better compression than traditional formats like JPEG or PNG, reducing file sizes without losing quality.
Resize images to match display sizes: Don’t load a 5000px-wide image if it’s only going to show at 300px.

Metrics impacted: Largest Contentful Paint (LCP), Speed Index

Reduce and Split Your JavaScript

JavaScript is powerful, but too much of it can cause delays in loading and make the browser unresponsive.

Bundle splitting: Tools like Webpack, Vite, or Next.js allow you to split your code into smaller chunks that are loaded only when needed.
Tree shaking: Remove unused code from third-party libraries during bundling.
Avoid unnecessary frameworks or heavy dependencies: Sometimes vanilla JS or lighter libraries can do the same job.

// webpack.config.js
module.exports = {
  entry: {
    main: "./src/index.js",
  },
  optimization: {
    splitChunks: {
      chunks: "all",
    },
  },
};

// Only importing what you need
import { debounce } from 'lodash-es';

// Instead of a full UI framework, use vanilla:
document.querySelector('#btn').addEventListener('click', () => {
  alert('Clicked!');
});

Metrics impacted: Total Blocking Time (TBT), Time to Interactive (TTI)

Use Lazy Loading

Lazy loading defers the loading of non-critical content, like images below the fold, until the user is about to see them.

Add the loading="lazy" attribute to <img> and <iframe> elements.
For background images or custom components, you can implement lazy loading with JavaScript.

This helps reduce the initial load size, speeding up the time it takes for your page to become interactive.

<img src="photo.jpg" loading="lazy" alt="Lazy-loaded photo">
<iframe src="video.html" loading="lazy"></iframe>

Metrics impacted: First Contentful Paint (FCP), Speed Index, LCP

Avoid Render-Blocking Resources

Render-blocking resources delay how quickly the browser can start rendering the page. These usually include large CSS files or scripts loaded in the <head>.

Minify and inline critical CSS to reduce blocking.
Defer non-essential JS using the defer or async attributes.
Use font-display: swap for web fonts to avoid text invisibility.

Metrics impacted: FCP, TTI, TBT

Enable Caching

Caching stores files locally so they don’t need to be downloaded again on future visits.

Use HTTP cache headers like Cache-Control or ETag.
Serve assets with hashed filenames (e.g., style.abc123.css) so browsers can cache them safely.
Use a service worker (especially for PWAs) to cache offline-friendly resources.

Metrics impacted: Repeat view performance, Time to Interactive, Speed Index

By applying these strategies, you're not just improving your Lighthouse score, but you’re making your site smoother, more responsive, and more enjoyable for everyone who visits.

Even small changes can lead to meaningful gains in user experience, which ultimately means better engagement, higher retention, and stronger SEO.

Hosting web app on your old Android phone

Guilherme Araujo — Sun, 20 Apr 2025 22:47:36 +0000

Recently, I was developing a simple bot to interact with a WhatsApp group. The code was pretty straightforward: a webhook that would read messages from the app and save data to a MongoDB database. As I continued working on the bot, I realized I needed to learn more about deploying such applications in real-world environments. To do this, I decided I wanted to self-host the application on a local server, like a Raspberry Pi, and started researching different models and their prices.

However, to my surprise, the prices for these devices had significantly increased due to a global chip shortage and the rising demand for Raspberry Pis. After spending some time looking at the inflated prices, I grew frustrated and began considering alternative solutions. That's when it hit me: I have an old Android phone – a Galaxy S9 – which is still quite powerful and functional even by today’s standards. Since it’s an Android, I wondered, could I run Linux on it?

Curious to explore this possibility, I began researching how I could run a Node.js application on my phone. Spoiler alert: it worked!

In this article, I’ll walk you through how I managed to turn my Galaxy S9 into a fully functional Node.js server using Termux. Along the way, I learned how Termux transforms an Android device into a powerful Linux environment, and how you can leverage your old phone as a local server for development or even small-scale production tasks. This setup can be incredibly useful if you’re looking to experiment or deploy projects without investing in extra hardware.

Installing Termux

The first step is to install Termux, which is a powerful terminal emulator for Android that provides a Linux-like environment.

Go to the Play Store on your Android phone and install Termux.

Opening Termux

Once installed, open the Termux app, and let’s start by updating all the Termux packages:

pkg update

Setting Up SSH Access

To make things easier and avoid constantly typing on the phone’s small keyboard, I decided to set up SSH so that I could access the phone remotely from my computer.

1- Install the openssh package:

pkg install openssh

2- Start the SSH server:

sshd

3- Find the Termux IP address:

ifconfig

4- Find the Termux username:

whoami

5- Set a password for SSH access:

passwd

Now, from your computer, you can connect to your phone via SSH:

ssh <username>@<Termux_IP_address>

At this point, you have a fully functional Linux environment running on your phone, and you can access it remotely via SSH.

Optionally, you can install tmux, a terminal multiplexer, which allows you to execute multiple applications in the same terminal session. I used tmux to manage tasks like port forwarding and running the Node.js application simultaneously.

Setting Up a Cloudflare Tunnel

To expose your application to the internet, you can use Cloudflare Tunnel. This will create a secure connection between your local server and the internet, making your Node.js application accessible.

1- Install cloudflared:

pkg install cloudflared

2- Run the following command to create a tunnel for your application:

cloudflared tunnel --url http://localhost:3000

Once the tunnel is running, you’ll be provided with a public URL that you can use to access your API from anywhere.

Installing Node.js

Termux makes it incredibly easy to install Node.js and start building applications.

1- To install Node.js, simply run the following command:

pkg install nodejs

2- Once Node.js is installed, you can start your Node.js application and expose it to the internet using the Cloudflare tunnel we set up earlier.

After completing these steps, my Node.js application was successfully running and publicly accessible, all from my old Android phone! I was able to deploy my bot, which interacted with the WhatsApp group and stored data in MongoDB, directly from my phone. This setup is surprisingly powerful and proves that you don’t need expensive hardware to host applications; an old Android phone can easily do the job.

Intercepting requests from WebView

Matheus Castro — Fri, 28 Mar 2025 15:26:25 +0000

Have you ever wondered how you can intercept ANY requests that your WebView makes in both Android and iOS?

Well, turns out that this is possible and not so hard to do.

Android

For Android it's actually pretty simple! You need to create a custom web view client and override the shouldInterceptRequest function. So it would look like this:

WebView(context).apply {
    ...
    webViewClient =
        object : WebViewClientCompat() {
            override fun shouldInterceptRequest(
                view: WebView,
                request: WebResourceRequest,
            ): WebResourceResponse? {
                val requestHost = request.url.host
                val isRequestAllowed =
                    allowedHostsList.entries.any { it.host == requestHost }
                if (isRequestAllowed) {
                    return null // Here you can return null or call super.shouldInterceptRequest(view, request)
                }

                return WebResourceResponse("text/html", "utf-8", 403, "Blocked", emptyMap(), ByteArrayInputStream(ByteArray(0)))
            }
        }
    ...
}

This method allows you to intercept the request and handle it as you may see fit. Remember that the request.url.host is a string that contains only the host, so no pathname or protocol there. If you want to get this information, you can get it from the request.url object.

iOS

For iOS it's not so straightforward. Actually there's no way to intercept the request, so we need to resort to a little trick. You can intercept navigation requests (going from one url to another), with WKNavigationDelegate, but not requests made by the javascript from the website, for example.

To our rescue, we can use WKContentRuleList, which in essence is a list that works in the same way as the content blockers from Safari (the browser).

We can use this content rule list to block requests to specific urls. First, we need to define the rule list, compile it and add to our webview. There's a gotcha, tough, we need to first block everything and then allow the domains we want (it's a trick, after all).

The rule list is a simple json array:

[
    {
                "trigger": {
                    "url-filter": ".*"
                },
                "action": {
                    "type": "block"
                }
    },
    {
                "trigger": {
                    "url-filter": "google.com"
                },
                "action": {
                    "type": "ignore-previous-rules"
                }
    }
]

The composition of the rule is pretty simple, you have a trigger object, and a action one.

The trigger key component is the url-filter, which accepts a regex to match the url, and .* will match all urls.
The action key component is the type, which will define what will happen for the matched url.

You can check the complete list of options for the trigger here and for the action block here.

In this example, we first block all requests, and then we allow only requests to google.com by defining the action of type ignore-previous-rules, which as the name implies, will ignore any rule that the url matched before.

After having your list set up, you need to compile and apply it to the userContentController.

let contentRulesList = """
[
    {
                "trigger": {
                    "url-filter": ".*"
                },
                "action": {
                    "type": "block"
                }
    },
    {
                "trigger": {
                    "url-filter": "google.com"
                },
                "action": {
                    "type": "ignore-previous-rules"
                }
    }
]
"""

let compiledContentRulesList = try await WKContentRuleListStore
                .default()
                .compileContentRuleList(
                    forIdentifier: "MyAppList",
                    encodedContentRuleList: contentRulesList
                )

webViewConfiguration.userContentController
                .add(compiledContentRulesList!)

After that, you are all set!

Conclusion

Now you know how to intercept and block/allow requests for webviews in both android and iOS.
For android it's pretty simple and straighforward, but for iOS we need the WKContentRuleList trick. Hopefully we will have a more direct way in the future.

Thanks for reading! If you have any questions, let me know.

You should be this type of developer

João Felipe — Thu, 13 Feb 2025 16:46:21 +0000

🎯 Introduction

There are a lot of developer types, but this one is always a good fit for the most projects or companies.

Have you ever worked with a developer who just ‘gets’ the product? Someone who doesn’t just code but also thinks about the user experience, business impact, and long-term product vision? That’s what a Product-Minded Developer is all about.

We have many benefits having this type of dev in our team:

Users: Usually, they think about the user experience first, not just about tech.
Context: Mainly because this dev has a lot of context about all the product, it's easier to create new features in different parts of the app.
Communication: Normally, the product-minded developers have a good relation with non-tech people, probably because they make sure to have an understandable communication (E.g., if the API endpoint is down, they can explain it to the product owner not using technical terms).
Time: They can save a lot of time for the team, because they can understand the product better.

For now, we'll explore some ways to be a product-minded developer.

🧠 A little obvious, but: Understand the product

The first step to be a product-minded developer is to understand the product.

You should ask questions, and you should be curious about the product. Make sure you know what problem the product is solving, and how it's being used.

Try to answer questions like:

What problem is the product solving?
Who is the product for?
How is the product being used?
What are the main features?

Tip: take a deep look at the landing page product, usually we have a really good summarized version of the product there.

👥 Get to know the users

You should know who the users of the product are, and what they expect from the product.

Try to answer questions like:

Who are the users?
- Normally, are they using the product on desktop, mobile, or both?
- What about the age? Are they already experienced or not?

For example, if the product you're working on is a CRM system, probably the device more used is desktop, so we don't need to care so much about the mobile experience.

❓ New features: a new opportunity to ask questions

When you're working on a new feature, you should ask questions about the feature.

Try to answer questions like:

What problem is the feature solving?
Why are we fixing this problem in that way and not in another?
Who is the feature for?

💼 Consider business goals, not just tech ones

When you're working on a feature or a bug, you should consider the business goals.

Try to answer questions like:

This piece of code is solving a problem, but is it solving the right problem?
Is this feature helping the business to achieve the goal?
Is this bug affecting the business?
How are we adding value to the user?

We, as developers, are normally focused on the code and some topics like performance, architecture, and so on. But, sometimes, we have choices to make, and we should consider the business goals.

🤝 Your product manager is your best friend

Your product manager is your best friend. They can help you to understand the product better, and they can help you to understand the users better.

Your tech lead will review your code, but usually they are not the best person to ask about the product.

Before starting a new project, it would be nice if you schedule a meeting with the product manager to understand the product better and ask questions about the context/market/users/etc.

💡 Come up with suggestions

You should come up with suggestions about the product. Think about it: you're a developer in this project/product, but you're a user in another one.

Try to think as a user, and come up with suggestions about the product.

For example, I was working on a feature that the visual was a form and a preview in a grid template, if the user changes the form, the preview should be updated, something like that:

If the user tries to change a field below in the form, the preview is fixed at the top of the page, creating a bad user experience.

I've suggested to the team to make the preview sticky, so it will follow the user when they scroll down the form.

A simple improvement, but in a large-scale project, it can save a lot of time for the users and create a better vision for our product.

🔑 Key Takeaways

Product-minded developers go beyond coding—they understand the product, users, and business.
Asking the right questions is crucial when developing features.
Collaboration with product managers leads to better decision-making.
Small UX improvements can have a big impact on the overall experience.

🎬 Conclusion

Being a product-minded developer is more than just writing great code, it's about understanding the bigger picture. When you deeply understand the product, its users, and the business goals, you become a more valuable team member, capable of making smarter decisions and delivering better experiences.

By asking the right questions, collaborating with product managers, and thinking beyond technical implementation, you can bridge the gap between development and product strategy. This mindset improves the quality of the product and makes your work more impactful and fulfilling.

At the end of the day, great products aren’t just built with great code, they're built with great perspective. So, be curious, stay engaged, and always think beyond the code! 🚀

How do you apply a product-minded approach in your work? Let’s discuss in the comments!

📝 Resources

The Product-Minded Software Engineer

Optimizing End-to-End Testing: Strategies for Speed, Reliability, and Efficiency

Guilherme Araujo — Mon, 27 Jan 2025 18:04:55 +0000

Best Practices for Efficient E2E Testing

Quick Overview: What Are E2E Tests?

End-to-End (E2E) tests are designed to run on top of your application, simulating real user interactions such as clicking buttons, typing input, navigating between pages, and more.

These tests are extremely useful for checking that entire workflows work as expected. For example, in an eCommerce application, an E2E test could simulate a complete purchase journey: selecting a product, adding it to the cart, registering a credit card, and completing the checkout process. By testing real-world scenarios, E2E tests help ensure your application's key features work well together.

Context

Recently, in my current project, we faced the task of restoring some old, skipped E2E tests. While working through them, we observed several opportunities for improvement. Many of these tests could be merged or rewritten in a more efficient way, and we realized that our approach of restoring the database for every test was significantly increasing the execution time.

Additionally, we identified potential to parallelize some of the test scenarios, which could further optimize our testing process. These observations led us to focus on techniques to improve performance, such as merging and optimizing test cases, leveraging parallelization, and rethinking our database restoration strategy. In this article, I'll share these strategies, primarily based on my experience using Playwright as an E2E testing tool. However, these techniques are likely applicable to most E2E testing frameworks.

Test Parallelization

Parallelization Across Files

Parallelizing tests is one of the most effective ways to speed up E2E test execution, especially as your test suite grows. By running multiple tests simultaneously, you can utilize your system's resources more efficiently and significantly reduce the total runtime.

In our project, we configured Playwright to use 5 workers by default. Each worker runs a test file independently, enabling up to 5 tests to execute at the same time. Here's how we set it up:

// playwright.config.js  
import { defineConfig } from '@playwright/test';  

export default defineConfig({  
  workers: 5, 
});

This simple change led to a significant improvement in test execution speed, as multiple tests could run concurrently.

However, some tests required rewriting due to side effects. For instance, certain tests created or modified resources that other tests depended on. When these tests ran in parallel, their execution order sometimes caused failures, as the shared state was not properly managed.

Parallelizing Tests Within Files

In addition to parallelizing tests across multiple files, we found that it’s also possible to enable parallel execution within a single test file. This approach is especially useful when you have multiple independent tests grouped in the same file and want to further optimize execution time.

In Playwright, this can be achieved by wrapping your tests in test.describe.parallel. All tests inside this block will execute simultaneously:

test.describe.parallel('Group of parallel tests', () => {  
  test('Test 1', async ({ page }) => {  
    // Test logic here  
  });  

  test('Test 2', async ({ page }) => {  
    // Test logic here  
  });  
});

Based on our experience parallelizing tests across files, the key principles remain the same:

Avoid Side Effects: Ensure that tests are fully independent and do not share or modify resources in a way that could interfere with other tests;
Reuse Resources Wisely: Manage shared resources, such as browser instances or test data, efficiently to prevent contention or conflicts during parallel execution. This technique can deliver a noticeable speedup for large test files, but it also requires careful planning to maintain test reliability and avoid flaky results. By isolating tests and managing resources effectively, you can take full advantage of parallel execution within files.

Pre-Authentication

Pre-authentication is a critical step to ensure that each test begins with a consistent, valid user session. This technique eliminates the need to repeatedly perform login actions for every test, significantly improving both speed and reliability in the tests, especially when tests are executed in parallel.

The approach involves leveraging Playwright’s ability to work with storageState, which stores session information (e.g., cookies, local storage) for pre-authenticated users. By restoring this state at the beginning of each test, the user is already logged in, allowing tests to focus on verifying functionality rather than navigating login flows.

test('User View - TEST_ID#153', async ({ browser }) => {  
  const context = await browser.newContext({
    storageState: path.join(__dirname, `../.auth/${email}.json`), // Pre-authenticated session
  });  
  const page = await context.newPage();  
  await page.goto('/'); // User is already logged in at this point
});

This approach guarantees that each test operates in isolation, preventing cross-contamination of session data. The pre-authenticated storageState ensures that tests skip redundant login steps, saving valuable time while maintaining consistency across the suite.

Of course, there are challenges to consider, such as ensuring that the .auth/${email}.json files are consistently updated with valid session data. Additionally, it's important to focus on the reusability of helper functions, avoiding tightly coupled data or risky code that could compromise the maintainability and reliability of the test suite.

Best Practices for Efficient E2E Testing

To maximize the efficiency of your E2E tests:

Prioritize Test Isolation: Ensure that tests are independent and avoid shared state wherever possible;
Minimize Dependencies: Pre-authentication and reusable helpers can reduce redundancy and improve test reliability;
Monitor Pipeline Performance: Regularly review test runtimes and resource utilization to identify bottlenecks or opportunities for optimization;
Balance Coverage and Execution Time: Focus on covering critical workflows without overloading the pipeline with unnecessary tests.

By adhering to these best practices, you can build a robust, scalable, and efficient E2E testing framework that delivers reliable results while saving time and resources.

Conclusion

Optimizing E2E tests is an ongoing process that involves balancing performance, reliability, and coverage. By leveraging techniques like test parallelization, pre-authentication, and careful resource management, you can significantly improve test execution times without compromising accuracy. While challenges such as side effects and maintaining reusable code require attention, the benefits of a well-optimized E2E suite far outweigh the effort. These practices, when implemented thoughtfully, pave the way for a more efficient and reliable testing process, enabling faster delivery of high-quality software.

Handling Promises with Higher-Order Functions in JavaScript

Guilherme Araujo — Tue, 17 Dec 2024 16:45:50 +0000

When working with arrays in JavaScript, you may find yourself needing to make asynchronous calls inside methods like forEach, .map, or similar functions. But after encountering errors or unexpected outputs, you might wonder, Why isn’t this working as expected? In this article, we’ll dive into these situations and explore how to handle promises effectively within higher-order functions.

What is a higher-order function?

Starting from the beginning:

A higher order function is a function that takes one or more functions as arguments, or returns a function as its result.

A simple example would look like this:

// Higher-order function that returns a function
function createAdder(x) {
  return function(y) {
    return x + y;
  };
}

const addFive = createAdder(5);
console.log(addFive(3)); 
// Console output: 8

What is a Promise?

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

A Promise is an object representing a value that may not be available yet but will be resolved in the future. Promises allow you to attach handlers to manage the eventual success or failure of an asynchronous operation, making it easier to handle responses as they arrive.

This pattern is especially useful in cases like:

API calls: When fetching data from external sources, such as RESTful APIs, the data may take time to arrive;
Database interactions: Querying a database can also be time-consuming, so promises allow you to handle the data only once it’s available.

Instead of returning the final data instantly, these asynchronous functions return a promise, which acts as a placeholder for the value that will be provided later.

Given these two concepts, let’s see how they interact.

Combining Promises with Higher-Order Functions: Practical Examples

Now that we understand promises, let’s look at a common use case: fetching data, such as retrieving user information from an array of user IDs:

const userIds = [1, 2, 3];

// Simulated async function to fetch user data
const fetchUser = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`User ${id} data`);
    }, 1000);
  });
};

❌ The Common Mistake: Not Handling the Array of Promises Properly
When using .map with an asynchronous function, a common mistake is forgetting that map will immediately return an array of promises instead of resolved values. Without additional handling, this leads to unexpected results:

const wrongWay = async () => {
  // This creates an array of promises, not resolved values!
  const users = userIds.map(async (id) => {
    return await fetchUser(id);
  });

  console.log(users); // Output: [Promise, Promise, Promise]
};

In this example, each call to fetchUser(id) returns a promise, so map returns an array of promises rather than the final data values. Simply awaiting inside .map doesn’t resolve the array itself; instead, it just creates a promise for each item in the array.

✅ The Correct Approach: Using Promise.all with map
To properly handle an array of promises, you need to use Promise.all. This method takes an array of promises and returns a new promise that resolves once all the promises in the array are fulfilled. Here’s how to use Promise.all to get the resolved data:

const rightWay = async () => {
  const users = await Promise.all(
    userIds.map(id => fetchUser(id))
  );

  console.log(users); // Output: ["User 1 data", "User 2 data", "User 3 data"]
};

.filter function

Like .map, the .filter function can lead to unexpected behavior when combined with asynchronous functions. Suppose we want to filter an array of user IDs to retrieve only the IDs of users that meet certain criteria, such as users with IDs that are "active."

Let’s take a look at a common mistake and how to avoid it.

❌ The Common Mistake: Using .filter with Async Functions

const isActiveUser = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      // Simulates checking if a user is active
      resolve(id % 2 === 0); // Returns true for even IDs, false for odd ones
    }, 1000);
  });
};

const wrongFilterUsage = async () => {
  const activeUsers = userIds.filter(async (id) => {
    return await isActiveUser(id);
  });

  console.log(activeUsers); // Output: [1, 2, 3] — the original array, not the filtered results
};

In this example, .filter doesn’t wait for isActiveUser(id) to resolve, so it operates on the original array of IDs rather than the resolved results. The array activeUsers ends up containing all user IDs, regardless of whether they are active, because the async function inside .filter doesn’t return the expected boolean.

✅ The Correct Approach: Using Promise.all with .map and .filter
To properly filter an array with an async function, we need to use .map in combination with Promise.all to resolve all promises first, then apply .filter on the resolved values. Here’s the correct approach:

const correctFilterUsage = async () => {
  // Use Promise.all to resolve the async checks for each user ID
  const results = await Promise.all(
    userIds.map(async (id) => ({
      id,
      isActive: await isActiveUser(id),
    }))
  );

  // Filter based on the resolved isActive status
  const activeUsers = results
    .filter(user => user.isActive)
    .map(user => user.id);

  console.log(activeUsers); // Output: [2] — only active user IDs
};

💡Promise.all
Using Promise.all offers several advantages for handling asynchronous tasks, especially when working with multiple promises simultaneously:

Parallel Execution of Requests: One of the primary benefits of Promise.all is its ability to execute multiple promises in parallel. When you pass an array of promises to Promise.all, it initiates all of them at the same time, allowing each promise to start processing concurrently. This can greatly improve performance by reducing the overall wait time, as all tasks are "in progress" together.

Example: If you’re fetching data for multiple users or making multiple API requests, Promise.all allows you to start each request without waiting for others to finish. This is particularly valuable for tasks where the order of execution doesn’t matter, like retrieving data from different sources.

⚠️ Caution: Use Promise.all carefully, as parallel execution may not always be ideal. For cases where tasks depend on one another or need to run sequentially (e.g., writing to a database in a specific order), parallel execution may cause issues. We’ll explore sequential handling methods later on.

Simplified Error Handling: Another powerful feature of Promise.all is its error-handling mechanism. If any promise in the array rejects, Promise.all will immediately reject with that error, allowing you to handle failures in a single .catch block. This makes error management more streamlined and efficient.

Note: Only the first rejection triggers the error; the remaining promises will continue to execute but won’t trigger further .catch blocks. If you need to capture each promise's result regardless of failure, consider using Promise.allSettled, which returns an array of outcomes for each promise, detailing whether they resolved or rejected.

Aggregated Results: Once all promises in Promise.all resolve, it returns an array of the resolved values, matching the order of the original promises. This makes it easy to work with the final results in a predictable way, even though each promise completes independently.

Summary Table

There are a lot of higher-order functions available in JavaScript, but here is a attempt to create a cheat sheet to make it easier to remember how the most common functions deal with asynchronous operations:

Method	Common Issue	Correct Solution
.filter	Returns array of promises	Use `Promise.all` with `.map`, then filter synchronously
.forEach	Doesn’t wait for async functions to complete	Use `Promise.all` with `.map` (parallel) or `for...of` with `await` (sequential)
.find	Doesn’t wait for async condition to resolve	Use `for...of` with `await` to find the first match sequentially
.reduce	Returns promise for each iteration	Use async `reduce`, awaiting the accumulator before each iteration

for...of for Sequential Async Processing

As mentioned earlier, simultaneous processing isn’t always ideal, especially when tasks depend on each other or could overload a server or API. In such cases, handling tasks sequentially can be beneficial, as it ensures that each task completes before the next one begins.

This is where the for...of loop becomes valuable. Unlike .map or .forEach, for...of allows you to await each asynchronous operation in sequence, ensuring that each task completes before moving on to the next. This approach is particularly useful in situations like making API calls that should occur in a specific order, processing a list of database writes sequentially, or handling rate-limited operations where triggering requests all at once could lead to errors.

An example of for...of:

const userIds = [1, 2, 3];

// Async function that simulates an API call
const fetchUserData = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`User ${id} data`);
    }, 1000);
  });
};

const fetchAllUserData = async () => {
  const userData = [];

  for (const id of userIds) {
    const data = await fetchUserData(id); // Each call waits for the previous one to complete
    userData.push(data);
  }

  console.log(userData); // Output: ["User 1 data", "User 2 data", "User 3 data"]
};

fetchAllUserData();

In this example, each fetchUserData call only starts after the previous one finishes, ensuring the operations are processed sequentially.

Wrapping Everything up

Working with asynchronous operations inside higher-order functions can be tricky and often leads to misunderstandings and unexpected results. Each method—whether .map, .filter, .forEach, .find, or .reduce —behaves differently with async functions, and recognizing these nuances is key to avoiding common mistakes. By understanding how each function handles promises and when to use tools like Promise.all or the for...of loop, you can significantly improve both the readability and reliability of your asynchronous code.

Hopefully, this guide will help clarify any questions that arise about how functions and promises behave in different scenarios.

Common Mistakes of a Developer Starting with Meteor.js

Guilherme Araujo — Mon, 28 Oct 2024 20:45:42 +0000

After nearly two months of working with Meteor.js, I find it valuable to document some of the most common mistakes I've made while using the framework. In this article, I’ll delve into the typical errors and questions I've encountered from fellow beginners, aiming to provide insights that can help others avoid the same pitfalls.

Poor optimized and unsafe Publications

On my first publication I've created a code like this:

export const Events = new Mongo.Collection('events');

Meteor.publish('events.list' => Events.find({ });

In the example above, we create a collection called events and then declare a publication called events.list that returns a collection cursor to the entire collection with all its fields. Once the client subscribes to it, all this data will be sent to the client and will be monitored for any updates that occur in the collection.

Although it might seem like magic, this reactivity comes with a significant computational cost. The system has to monitor the entire collection, compare the differences between new and old data, and update the client with each change.

Optimizing your Publication

To create performatic and optimized queries we need to understand some concepts about the publications we create:

Use Filters to Retrieve Relevant Data: Applying filters in your find({ }) queries is crucial for ensuring that only relevant data is retrieved from the database. Filters allow you to precisely define the subset of data you want to fetch, based on conditions such as user ID, date range, or any other criteria. By doing so, you avoid retrieving unnecessary or irrelevant records (e.g., data belonging to other users or outdated entries), which could unnecessarily increase the amount of data sent to the client.
Well-designed filters not only enhance security by ensuring that users only receive their own data but also reduce both server load and network traffic by minimizing the data processed and transmitted;
Leverage Projections for Fine-Grained Control: Projections allow you to retrieve only the specific fields you need from your documents, instead of sending the entire document to the client. This prevents large, unnecessary objects from being transferred and reduces memory overhead on the client-side. By sending only the essential fields, you also optimize memory usage and minimize the load on the client's processing.
For example, if you only need the name and date of the event, you can write:

Meteor.publish('events.list' => 
  Events.find({ }, { fields: { name: 1, date: 1 } }
);

Paginate Large Data Sets: If you are working with large data sets, consider implementing pagination. This allows you to send data in smaller, more manageable chunks, improving performance and providing a smoother user experience;
Security - Protect Sensitive Data: Publishing entire collections without any restrictions can unintentionally expose sensitive data from your application. This is a significant security risk. By applying filters and projections, you can control exactly what data is sent to the client, ensuring that only the necessary and non-sensitive information is exposed. This practice not only optimizes performance but also safeguards your application by preventing unintended data leaks.

After passing thru all these concepts, now we can refactor our initial subscription:

import { check } from 'meteor/check';

Meteor.publish('events.list', function (page) {
  if (!this.userId) {
    return this.ready(); // Stop publication if the user is not authenticated
  }

  check(page, Number);
  if (!page || page <= 0) page = 1;

  const LIMIT = 10;

  // Calculate how many documents to skip based on the page number
  const skip = (page - 1) * LIMIT;

  return Events.find(
    { userId: this.userId }, // filter by current user's events
    {
      fields: { name: 1, date: 1 }, // only return necessary fields
      limit: LIMIT,                 // limit the number of documents returned
      skip: skip                    // skip documents based on page number
    }
  );
});

Too much reactivity - useSubscribe everywhere

As mentioned earlier, leveraging subscriptions in Meteor.js can feel like magic, providing you with reactive data on the front-end with minimal effort. However, over-relying on this feature can lead to messy, hard-to-debug, and inconsistent code.

When a document is published by the back-end and you subscribe to it on the front-end, the data is stored in a client-side in-memory database called minimongo. This allows you to easily access data using Collection.find({}) or Collection.findOne({}). But as your project scales and multiple components manage the same data, this can become complicated.

For instance, consider a details page that follows a listing. If your subscription is placed within the listing component and a user navigates directly to the details page via the URL, the required data may not be available for display.

To avoid this issue, it’s essential to understand where data is being used and to evaluate whether it truly needs to be reactive. Using Meteor methods allows you to fetch data like a standard HTTP call from your back-end, eliminating the guesswork about data availability. This approach not only simplifies data management but also enhances performance by reducing unnecessary reactivity, leading to cleaner and more maintainable code.

Data Merge Issues

One common challenge in Meteor.js arises from managing multiple subscriptions, especially when dealing with overlapping data. This can often occur due to an excessive number of subscriptions or a misunderstanding of how publications work.

Consider the following example, where two subscriptions pull different fields from the same collection:

return Events.find({}, { fields: { date: 1, host: 1 } });
return Events.find({}, { fields: { 'host.name': 1 } });

On the client side, Meteor only maintains a single copy of each document, regardless of how many subscriptions exist. The server determines which fields to send to the client using a mechanism called the 'MergeBox'. Ideally, with both of these subscriptions active, the client would have the complete host data, since one subscription provides the full host object and the other supplies only a partial view.

However, the MergeBox operates only at the top field level, as explained in Meteor's documentation:

If more than one subscription sends conflicting values for a field (same collection name, document ID, and field name), then the value on the client will be one of the published values, chosen arbitrarily.

This means documents aren’t deeply merged. Sometimes, the full host from the first publication will be displayed, while other times, the client may receive only the partial host.name from the second publication, leading to inconsistent data on the front-end.

Sorting in Publications

When a client subscribes to a publication, the data it receives is merged with existing data in the client’s minimongo store. This merging process doesn’t always respect the original sorting order from the server, which can result in records being displayed in an incorrect order.

To avoid this, it's often unnecessary to handle sorting within the publication itself unless the order of the data is dynamic (e.g., for pagination or live updates). Instead, you can delegate sorting to the front-end when retrieving data from minimongo. This ensures the data is always presented in the desired order without risking a mix-up due to how subscriptions are processed.

For example, you can apply sorting directly when querying your local collection on the client:

Events.find({}, { sort: { date: -1 } });

Conclusion

Working with Meteor.js offers a powerful and flexible way to build real-time applications, but like any framework, it comes with its own set of challenges. Through my experience, I’ve learned that understanding the inner workings of subscriptions, data reactivity, and minimongo is crucial for avoiding common pitfalls. Over-reliance on reactivity can lead to performance issues, and managing multiple subscriptions without proper planning can cause data inconsistencies.

By taking control of data flow—whether by strategically using Meteor methods for non-reactive data, managing data subscriptions at higher levels, or handling sorting on the client side—you can ensure cleaner, more maintainable code. With careful consideration of these practices, your Meteor.js projects will not only perform better but also be easier to debug and scale.

Special thanks to my teammates João Ladeira, Isaque, and Renan for helping me understand these concepts and rescuing me from these pitfalls.

Impostor Syndrome Doesn’t Define You, Dev

João Felipe — Fri, 25 Oct 2024 13:44:33 +0000

If you're a developer, you've probably experienced moments when you lack confidence in making decisions or feel like you don't deserve to be where you are.

This feeling has a name: Impostor Syndrome. In this post, we'll explore some ways to deal with it.

Have a mentor

First of all, it would be really cool if you had a mentor, someone with more experience than you, probably some senior developer or tech lead from your company.

A mentor can guide you with the best practices, technically and non-technically (like communication or leadership).

With their experience, they can help you identify where you're doing well, where you're struggling, and where to focus your efforts. And this is awesome for you, if you know it, it's much easier to take the right steps to grow your skills and become a better developer.

Understand what they expect from you

You have a mentor, right? Now, you need to understand what is expected from you. To do this, my best advice is a little bit obvious but efficient: ask it.

"What do you expect from me?"
"In 6 months, what do I need to achieve for you to be sure that hiring me was worth it?"
"What are the characteristics you expect me to demonstrate in my daily work?"

You can schedule a call with your mentor/leader and ask some questions like that. You'll demonstrate interest, and you'll have the details of expectations.

Come up with a plan

You already know what they want from you, it's time to create a plan to achieve it.

There are a lot of ways to create this plan, you can select some books to read or even define some goals for your week.

But my main advice is: be practical. Create some tasks based on what they literally expected from you.

A communicative developer? Create reports every month to your leader with your best tasks.
A programmer addicted to learning/curious? Write some posts about your learning and share them with your coworkers.

In a nutshell, create practical tasks to achieve what they expect from you.

You'll not achieve all these skills overnight, relax and enjoy the process.

Ask for feedback, A LOT

How will you know if you are getting better or not? Feedback!

Seriously, feedback will be your best friend in dealing with imposter syndrome and being more confident. With it, you'll receive some compliments (it'll increase your confidence) and some negative reviews, which are ok, nobody is perfect.

"But how regularly should I ask for feedback?"

In my humble opinion: the more, the better. If you can ask it every single day, ask it.

Create something new

Sometimes, when you work on the same project/product for a long time, you'll feel that you are not learning or improving.

You'll say to yourself: "I'm doing the same thing every single day, it is not making me better.".

To keep learning and FEEL that you are learning, my advice is to create some personal projects. You can test that tool that you thought was nice, but your company does not use it.

Share this knowledge with the community, You can create a post on LinkedIn about your project and describe what you learned.

Be careful with AI

The AI is here to help our lives, Cursor is a good example. But be careful about it, tools like these can affect your confidence.

Have you ever felt indestructible when you finished a very hard task? Or when you finally discovered the solution to that problem, for example. Actions like these increase our confidence because they show that we can solve problems and create nice things.

You MUST practice your code skills, whether formatting some complex data, creating a more reusable component for FE, or learning what you should do to reduce the API response time. You must know how to solve these problems, not just how to create the best prompt to get the solution.

Summing up, use AI for productivity and automation, but not as a crutch.

Conclusion

To cut a long story short, this article described 6 topics that can help you to feel more confidence and improve your skills.

Moreover, the text makes it clear that you are not alone, you are not the first, and you'll not be the last who feels like a fraud.

Finally, feel free to share more ways to deal with this feeling.

Configurando Caddy: Arquivos Estáticos e Autenticação Básica atrás de um Load Balancer

Edimar Cardoso — Thu, 03 Oct 2024 19:09:11 +0000

O Caddy server tem se mostrado um projeto muito promissor. Além de ser rápido, tem muitas funcionalidades "built-in" que facilitam muito a configuração. Um dos exemplos é a emissão automática de certificados SSL. Além disso, é muito fácil configurar um serviço utilizando ele.

Esta semana, precisei criar um serviço para publicar arquivos estáticos. Ao tentar fazer isto com a configuração padrão dele, notei que não seria possível usar a configuração padrão por ter um cenário um pouco diferente.

No meu cenário, o serviço iria rodar atrás de um load balancer na zCloud que já é responsável por gerar os certificados e fazer a terminação do TLS/SSL. A configuração padrão gerou problemas pois não deveria gerar certificado SSL, apenas servir os arquivos na porta HTTP padrão.

Além disso, havia outra particularidade: precisava de um endpoint de health check com acesso público, enquanto todo o restante precisava ser bloqueado utilizando autenticação padrão "Basic Auth".

A seguir, o arquivo utilizado para fazer isto de uma forma bem simples:

{
  auto_https off
}
:8080 {
    route /_health* {
        respond 200
    }
    route {
        basic_auth / {
            USER_NAME HASH_PASSWORD
        }
        root * /var/www/static
        file_server
    }
}

Explicando um pouco sobre a configuração:

Desabilitando SSL

auto_https off

Desabilita a emissão automática de certificado e desabilita o redirecionamento para HTTPS.

Porta

:8080 {
# ...

Porta que será aberta para receber conexões.

Health check

    route /_health* {
        respond 200
    }

Rota para acesso ao health check com acesso público.

Arquivos estáticos com autenticação

    route {
        basic_auth / {
            USER_NAME HASH_PASSWORD
        }
        root * /var/www/static
        file_server
    }

Esta parte da configuração irá receber todo restante das requests, interceptar as requisições e forçar um login, caso o usuário não esteja logado, e servir os arquivos do diretório /var/www/static.

O valor USER_NAME é o nome do usuário que será usado para autenticar.
O valor HASH_PASSWORD é o hash gerado pelo CLI do Caddy com base na senha definida. Para gerar este valor, basta seguir as instruções na documentação oficial basic_auth.

Conclusão

Esta configuração do Caddy Server oferece uma solução elegante para servir arquivos estáticos com autenticação, ao mesmo tempo que permite um endpoint de health check público. A flexibilidade e simplicidade do Caddy tornam-no uma excelente escolha para diversos cenários de deploy.

Using Caddy to Serve Static Files Behind a Load Balancer

Edimar Cardoso — Thu, 03 Oct 2024 19:07:34 +0000

Caddy server has proven to be a very promising project. Not only is it fast, but it also has many built-in features that greatly simplify configuration. One example is the automatic issuance of SSL certificates. Moreover, it's very easy to set up a service using Caddy.

This week, I needed to create a service to publish static files. When trying to do this with Caddy's default configuration, I noticed it wouldn't be possible due to a slightly different scenario.

In my scenario, the service would run behind a load balancer at zCloud that's already responsible for generating certificates and handling TLS/SSL termination. The default configuration caused issues because it shouldn't generate an SSL certificate, but only serve files on the default HTTP port.

Additionally, there was another particularity: I needed a health check endpoint with public access, while everything else needed to be blocked using standard "Basic Auth" authentication.

Here's the file used to accomplish this in a simple way:

{
  auto_https off
}
:8080 {
    route /_health* {
        respond 200
    }
    route {
        basic_auth / {
            USER_NAME HASH_PASSWORD
        }
        root * /var/www/static
        file_server
    }
}

Let's break down the configuration:

Disabling SSL

auto_https off

This disables automatic certificate issuance and disables redirection to HTTPS.

Port

:8080 {
# ...

This specifies the port that will be opened to receive connections.

Health check

    route /_health* {
        respond 200
    }

This route provides public access to the health check endpoint.

Static files with authentication

    route {
        basic_auth / {
            USER_NAME HASH_PASSWORD
        }
        root * /var/www/static
        file_server
    }

This part of the configuration will receive all other requests, intercept them and force a login if the user is not logged in, and serve files from the /var/www/static directory.

The USER_NAME value is the username that will be used for authentication.
The HASH_PASSWORD value is the hash generated by the Caddy CLI based on the defined password. To generate this value, simply follow the instructions in the official basic_auth documentation.

Conclusion

This Caddy Server configuration offers an elegant solution for serving static files with authentication while allowing a public health check endpoint. Caddy's flexibility and simplicity make it an excellent choice for various deployment scenarios.

AI, Cursor, Verbosity and Meteor without frontend frameworks

Filipe Névola — Sun, 29 Sep 2024 13:40:36 +0000

Cursor: Changing the IDE Game

Cursor provides three modes: Inline, Composer, and Chat. These modes offer unique ways to interact with AI during coding. However, they are not without their drawbacks.

You might want to skip this section if you're a VSCode enthusiast who's never experienced JetBrains IDEs. As I say, ignorance is bliss, especially when it comes to food taste and IDEs.

For those familiar with more robust IDEs, Cursor's limitations become apparent:

Code navigation features are lacking (find usages, go-to reference, go-to implementation, etc.)
Git integration is limited
Search, find, and replace capabilities are weak

I know it inherits all of VSCode's issues, but even when I configure 30+ keyboard shortcuts to do things I do naturally on JetBrains IDEs, the experience is still sufferable.

What is the possible best setup today?

Use Cursor for AI-specific coding tasks and WebStorm (or other JetBrains IDEs) for everything else. The dream scenario would be JetBrains shamelessly copying all of Cursor's features.

Cursor's AI capabilities shine because it:

Utilizes Claude 3.5 Sonnet
Provides three distinct interaction methods
Allows Composer to modify and create multiple files simultaneously
Offers separate diff and apply actions

Imagine having JetBrains' superior diff feature in Cursor – that would be a game-changer.

To expand on "AI-specific coding tasks":

I still prefer to code myself in many cases, though I expect these instances to decrease over time. I believe the sweet spot for AI now is handling simple tasks, especially in unfamiliar projects or when dealing with verbose tasks.

Verbosity: No Longer a Developer's Nemesis?

Verbosity has long been a thorn in developers' sides, but AI-generated code is shifting this paradigm. This change could make verbose languages like Java and tools like TailwindCSS more palatable to developers.

Meteor Frontend Without Frameworks: A Fresh Perspective

Exploring Meteor's reactivity without client-side frameworks unveils how powerful the Meteor's reactive model is on its foundation. Here's a quick demo:

// Function to render the video list
function renderVideoList(videoList) {
  let content = `
    <h2>YouTube Videos</h2>
    <div>
      <input type="text" id="newVideoUrl" placeholder="Enter YouTube URL">
      <button id="addVideoBtn">Add Video</button>
    </div>
    <ul>
  `;
  content += videoList.map(video => `
    <li>
      ${video.url}
      <button onclick="removeVideo('${video._id}')">Remove</button>
    </li>
  `).join('');
  content += '</ul>';
  renderHTML('app', content);

  // Add event listeners
  document.getElementById('addVideoBtn').addEventListener('click', addVideo);
  document.getElementById('newVideoUrl').addEventListener('keypress', handleNewVideoKeyPress);
}

// Simple function to render HTML using JavaScript
function renderHTML(elementId, content) {
  const element = document.getElementById(elementId);
  if (element) {
    element.innerHTML = content;
  } else {
    console.error(`Element with id "${elementId}" not found.`);
  }
}

window.removeVideo = async function(videoId) {
  try {
    await Meteor.callAsync('videos.remove', videoId);
    // If successful, the UI should update automatically if you're using Tracker or ReactiveVar
  } catch (error) {
    console.error('Error removing video:', error);
    // Optionally, show an error message to the user
  }
};

Meteor.startup(() => {
  console.log('Meteor.startup');
  Meteor.subscribe('youtubeVideos');

  // Set up the reactive computation
  Tracker.autorun(() => {
    const videoList = YoutubeVideosCollection.find().fetch();
    renderVideoList(videoList);
  });
});

As you can see, this HTML was generated by AI, so it was "coded in English," and I didn't have to type anything. Meteor's powerful foundation allowed me to create very simple code that is reactive and updates the UI in real-time without any UI framework.

Why does this matter, and why I'm talking about it in this post?

Because AI can now generate HTML based on natural language requests with ease and speed.

Conclusion: Embracing the New Era

While we're not suggesting abandoning frameworks altogether, we're undoubtedly entering a new age where verbosity is becoming less of an issue for developers. It's time to consider embracing new patterns and languages.

Good libraries and frameworks offer much more than just reducing verbosity. They optimize performance for common cases and propose innovative solutions to problems. However, exploring life without them is occasionally beneficial, as this can lead to fresh ideas and perspectives.

As a bonus insight: TailwindCSS's verbose nature, once considered a drawback, is now less significant in the age of AI-assisted development. Some might call this lucky timing, but as the saying goes, "luck favors the prepared." TailwindCSS's success is a testament to its creators' hard work and foresight, who positioned themselves perfectly for this new era of development (with a good pinch of luck).

DEV Community: Quave

Building Reactive Lists with Meteor and Blaze

The Problem with Lists

Reactive List with #let

Should I use #let or ReactiveVar?

Wrapping Up

Understanding Lighthouse: The Metrics That Actually Matter for Performance and SEO

🔍 What Is Lighthouse?

Performance

How Are Lighthouse Scores Calculated?

What About the Other Categories?

🚀 How to Improve Your Scores

Optimize Images

Reduce and Split Your JavaScript

Use Lazy Loading

Avoid Render-Blocking Resources

Enable Caching

Hosting web app on your old Android phone

Installing Termux

Opening Termux

Setting Up SSH Access

Setting Up a Cloudflare Tunnel

Installing Node.js

Intercepting requests from WebView

Android

iOS

Conclusion

You should be this type of developer

🎯 Introduction

🧠 A little obvious, but: Understand the product

👥 Get to know the users

❓ New features: a new opportunity to ask questions

💼 Consider business goals, not just tech ones

🤝 Your product manager is your best friend

💡 Come up with suggestions

🔑 Key Takeaways

🎬 Conclusion

📝 Resources

Optimizing End-to-End Testing: Strategies for Speed, Reliability, and Efficiency

Best Practices for Efficient E2E Testing

Quick Overview: What Are E2E Tests?

Context

Test Parallelization

Parallelization Across Files

Parallelizing Tests Within Files

Pre-Authentication

Best Practices for Efficient E2E Testing

Conclusion

Handling Promises with Higher-Order Functions in JavaScript

What is a higher-order function?

What is a Promise?

Combining Promises with Higher-Order Functions: Practical Examples

.filter function

Summary Table

for...of for Sequential Async Processing

Wrapping Everything up

Common Mistakes of a Developer Starting with Meteor.js

Poor optimized and unsafe Publications

Optimizing your Publication

Too much reactivity - useSubscribe everywhere

Data Merge Issues

Sorting in Publications

Conclusion

Impostor Syndrome Doesn’t Define You, Dev

Have a mentor

Understand what they expect from you

Come up with a plan

Ask for feedback, A LOT

Create something new

Be careful with AI

Conclusion

Configurando Caddy: Arquivos Estáticos e Autenticação Básica atrás de um Load Balancer

Desabilitando SSL

Porta

Health check

Arquivos estáticos com autenticação

Conclusão

Using Caddy to Serve Static Files Behind a Load Balancer

Disabling SSL

Port

Reactive List with `#let`

Should I use `#let` or `ReactiveVar`?