Forem: Fabian Frank Werner

Uh oh... Cloudflare just turned evil

Fabian Frank Werner — Sun, 22 Mar 2026 23:00:00 +0000

So, the headline today is that Cloudflare—the company famous for being the absolute, undisputed bouncer of the internet—just released a brand new tool for developers. And the tool... is a bot. A web scraper. The big, hilarious irony here is that the company that has spent the last decade building the most sophisticated anti-bot protection on the planet, just handed developers a master key to scrape the web for AI.

Now, if you’re a developer, or you’re building AI apps, or you run a startup, this is a massive deal. It is fundamentally shifting the landscape of how data gets fed to large language models. But if you missed the announcement, or the absolute chaotic reaction to it on Twitter over the last few days, we really need to dive into this. Because on one hand, this new tool is an absolute masterclass in infrastructure engineering. But on the other hand, it has put Cloudflare in this incredibly comical, paradoxical position in the market. And it is actively sending shockwaves through a whole ecosystem of startups—like Firecrawl—who specialized in doing exactly what Cloudflare just made essentially native.

Part 1: Anti-bot. Pro-web.

Let’s rewind and set the stage. If you use the internet—which, assuming you are watching this video, you do—you know Cloudflare. They handle the traffic for roughly 20 percent of the entire web. When you go to a website and get that little 'Checking if you are human' box, or you get blocked because your IP looks suspicious, that’s Cloudflare.

Over the last couple of years, as the AI boom took off, we entered this era of aggressive web scraping. Companies building LLMs, RAG pipelines, and AI agents were just relentlessly hammering websites to extract training data. It was a complete free-for-all. Website owners were furious because their server bills were skyrocketing while getting zero real human traffic. So, Cloudflare stepped in as the hero. They rolled out one-click toggles to block AI bots. They introduced 'AI Crawl Control.' They established themselves as the credible, responsible adult in the room, protecting the open web from the AI data vampires.

Part 2: Hello, Crawler!

Which brings us to March 10th, 2026. Just a few days ago, the Cloudflare Developers account on X posted the announcement for a brand new open beta feature in their Browser Rendering suite: The crawl endpoint. The pitch is simple: One API call, and an entire site is crawled. No scripts to write. No headless browsers to manage. Just pure content returned in HTML, Markdown, or structured JSON. Let that sink in. The company that stops bots just released a managed, scalable bot as a service.

If you look at their official REST API docs, this endpoint is basically magic for developers building AI tools. You send a single POST request to the API with a starting URL. That’s literally it.

Cloudflare’s infrastructure automatically discovers the pages, spins up a headless browser to render the JavaScript, extracts the content using Workers AI, and hands you back a job ID. Because it runs asynchronously, you just check back with a GET request, and boom—perfectly structured data ready for your RAG pipeline. You don't have to set up Puppeteer. You don't have to hunt for complex CSS selectors. And Cloudflare even baked in features like modifiedSince and maxAge to do incremental crawling, saving you compute time.

But this is where the market positioning becomes so incredibly funny, and why the internet is making so many memes about it. Cloudflare is essentially saying, 'We protect websites from scrapers... unless it’s our scraper.' But, to be completely fair to Cloudflare, they are playing by the rules. If you dive into their robots.txtdocumentation for this new endpoint, they are very explicit: This is a polite bot.

Cloudflare hardcoded the User-Agent to CloudflareBrowserRenderingCrawler/1.0. You cannot change it. You cannot spoof it. It rigorously respects robots.txt files, crawl delays, and most importantly, it obeys Cloudflare’s own AI Crawl Control. So, if a site owner flips the switch to block AI bots, Cloudflare’s own bouncer will kick its own bot out of the club. It’s the ultimate 'I am playing both sides so I always come out on top' strategy.

Part 3: Friendly fire...

But let's talk about the real casualties of this announcement. Because this isn't just about Cloudflare being hypocritical. This is about what happens to the startups that were built in the gap that Cloudflare just closed. Enter Firecrawl.

If you haven't heard of Firecrawl, they are an absolutely brilliant startup, specifically built for the AI era. Their entire value proposition is turning complex websites into clean Markdown and structured JSON for AI agents. They handle the hard stuff—rotating proxies, bypassing captchas, rendering complex Single Page Applications. They have thousands of stars on GitHub and became the absolute darling of the AI developer community.

A huge part of Firecrawl’s appeal was that it was really good at getting past... you guessed it... Cloudflare’s anti-bot protections. If you've ever tried to scrape a site and got hit with a Cloudflare 403 Forbidden error, Firecrawl was the tool you paid for to make that headache go away. And now? Cloudflare essentially looked at Firecrawl's entire business model and said, 'Yeah, we'll just build that directly into our edge network.'

It is the textbook definition of being 'Sherlocked.' Cloudflare’s new crawl endpoint does exactly what Firecrawl does, but it runs natively on Cloudflare’s infrastructure. And the limits are aggressive. On the free tier, developers get 5 crawl jobs a day with up to 100 pages per crawl. On the paid Workers plan? It’s massive. Developers are already pointing out that integrating this native endpoint is an order of magnitude cheaper and faster than paying for a specialized third-party scraping service. An entire startup's moat just evaporated overnight by an infrastructure giant.

So what does a company like Firecrawl do in the coming months? Because they are going to have a hard time, and they need to pivot fast. If I'm Firecrawl, I can't compete on basic markdown extraction anymore. Cloudflare won that race. But remember, Cloudflare's crawler is locked into being a polite bot. It respects the rules.

Firecrawl might have to lean heavily into being the 'unpolite' bot—the one that uses advanced residential proxies and browser fingerprinting to scrape sites that actively want to block scrapers. Basically, when Cloudflare's polite bot hits a wall, you call Firecrawl. The other pivot is deep, agentic interaction. Cloudflare’s endpoint is passive; it loads the page, runs the AI prompt, and returns data. Firecrawl has to double down on features that let an AI actively click buttons, fill out login forms, and navigate behind authentication walls. They have to become an AI agent workspace, not just a data pipe.

Part 4: Gatekeeper. Gateway. Tollbooth.

But zooming out, this whole situation is a fascinating case study in market dynamics and the future of the web. All these headlines and Twitter threads are funny: 'Cloudflare is the bot and the anti-bot.' But it popped this thought into my head that maybe, in the modern AI era, who owns the smartest Large Language Model is not as important as who controls the training data pipeline.

We have OpenAI, Google, and Anthropic spending billions on compute to train models. But those models are starving for high-quality, real-time web data. Cloudflare sits directly in front of that data. They are the tollbooth. For a year, they used their power to shut the gates and protect the publishers. And now, with the crawl endpoint, they are opening a sanctioned, highly controlled side-door.

They aren't just a Content Delivery Network anymore; they are positioning themselves as the primary data broker for the entire artificial intelligence industry. If you want the data cleanly, legally, and cheaply, you go through Cloudflare. It is a brilliant business move. It is hilarious market positioning. And it is absolutely terrifying if you are a startup trying to build middleware on the internet.

But I am really curious what you all think. For the developers watching this—are you going to drop your current scraping setups and move everything over to Cloudflare's new native crawl endpoint? Do you think specialized tools like Firecrawl are doomed, or do they still have a place in your stack for handling the really hard, dirty work of scraping behind logins? And honestly, how do you feel about Cloudflare playing both the cop and the getaway driver in the AI data heist?

Elysia in 100 Seconds

Fabian Frank Werner — Sun, 01 Feb 2026 23:00:00 +0000

ElysiaJS. A high-performance, statically typed web framework famous for being faster than your caffeine jitters. It makes you realize how slow Express actually is.

It’s the framework of choice for developers who want the raw speed of the Bun runtime but still want their code to look like it was written by a human.

It was created in 2022 by the developer SaltyAom. And it’s widely believed to be named after the character Elysia from Honkai Impact 3rd. Because high-performance software engineering and anime addiction are basically the same Venn diagram at this point.

Elysia was built to solve a specific problem: Type safety usually comes with a tax—either a runtime performance penalty or extensive boilerplate. Elysia cheats the system by leveraging Bun's Just-In-Time compiler and TypeBox to give you end-to-end type safety with zero code generation. Unlike NestJS, you don't need a PhD in decorators to define a route, and unlike Express, it won't let you ship broken code to production.

To get started, install Bun, then create a file ending in .ts.

Initialize the app by calling new Elysia().

Define your logic using a chainable, fluent API. Use .get() to define a route. Notice how there are no complex return types—just return an object, and it automatically serializes it to JSON.

But the real magic happens when you handle data. Add a schema object to the route using the t variable. This validates incoming data at runtime and automatically infers the TypeScript types for your IDE. If you try to access a property that doesn't exist, the compiler yells at you before you even run the code.

It even features the "Eden Treaty," a system that allows your frontend to import the backend's type definitions directly, giving you autocompletion for your API calls on the client side.

Now, compile and run your code with bun run, and watch your server start up in microseconds.

Python vs Ruby - I built the same github analyzer with both

Fabian Frank Werner — Sun, 18 Jan 2026 23:00:00 +0000

If you are picking a high-level programming language today, there are two competing heavyweights. In the red corner, we have Ruby—the language designed for developer happiness; and in the blue corner, we have Python—the data juggernaut that ate the world.

Both tools achieve the same fundamental goal: they let you build powerful applications fast. But there is a world of difference in the philosophy. No matter which one you choose, the other one automatically becomes your arch-nemesis. Because you don’t choose anything but the absolute best technology out there.

To figure out which one is best, I built the exact same GitHub Repository Analyzer with both Python and Ruby.

In today’s video, we are going to dive into a detailed side-by-side comparison of the syntax, data processing, web frameworks, performance, and of course, the ecosystem! By the end of this video, you will know exactly which one fits best into your ideology.

But this isn't a line-by-line coding tutorial. If you want to learn how to build these apps from scratch, then subscribe to my newsletter.

The tool I built is a web application that takes a GitHub username and repository name as input. It hits the GitHub API, fetches the commit history, and analyzes the data to tell us:

Who is the most active contributor?
What days of the week are most productive?

For the Python version, we are using Flask for the web server and Pandas for the data crunching.

For the Ruby version, we are using Sinatra (the grandfather of micro-frameworks) and pure Ruby Enumerables to prove a point about the standard library.

Let's talk about the first thing you do: setting up your environment. This is where the pain begins.

In Python, we need to isolate our dependencies. If you are a beginner, you Google "how to install packages." You see pip install. You do it. And suddenly, you have installed a library globally on your system, breaking your OS-level Python.

So, you learn about Virtual Environments.

python -m venv venv
source venv/bin/activate

You create a requirements.txt file. But wait, requirements.txt is dumb. It doesn't handle dependency resolution well. So maybe you should use Poetry? Or Pipenv? Or Conda? Or Rye? The Python ecosystem is currently in a civil war regarding packaging. It works, but it feels like assembling IKEA furniture without the instructions.

Now, let's look at Ruby.

Ruby has had this solved for over a decade. It’s called Bundler.

You create a file called Gemfile.

source 'https://rubygems.org'
gem 'sinatra'
gem 'httparty'

You run bundle install. That's it. Bundler manages your dependencies, locks the versions in a Gemfile.lock, and ensures that if I send this code to you, it works exactly the same way. It is the gold standard that every other language, including JavaScript's npm and Rust's Cargo, tried to copy.

Now we write the code. This is where the religious war happens.

Python is famous for significant whitespace. It uses indentation to define blocks of code.

def analyze_repo(user, repo):
    if user:
        print(f"Analyzing {repo}...")
    else:
        print("No user provided.")

If I mess up the indentation by one space—just one space—the program crashes. IndentationError. This forces you to write clean code. You physically cannot write messy, unindented Python. It enforces structure. It is visual discipline.

Now, look at Ruby. Ruby doesn't care about your whitespace. It cares about keywords. Specifically, the word end.

def analyze_repo(user, repo)
  if user
    puts "Analyzing #{repo}..."
  else
    puts "No user provided."
  end
end

See that? No colons. No required indentation (though you should indent). But you have to close everything with end.

But the difference goes deeper. Python believes in "Explicit is better than implicit."

If you want to access a variable, you name it. If you want to return a value, you type return.

def greet(name):
    return f"Hello, {name}"

Ruby believes in Magic.

In Ruby, the last line of a function is automatically returned. You don't need to type return. Parentheses are optional.

def greet name
  "Hello, #{name}"
end

Python looks like a blueprint. Ruby looks like a sentence.

Let's hit the GitHub API.

In Python, we use the library requests. It is arguably the most famous Python library ever written. Its tagline is "HTTP for Humans."

import requests

def get_commits(user, repo):
    url = f"https://api.github.com/repos/{user}/{repo}/commits"
    response = requests.get(url)
    return response.json()

It is beautiful. It is simple. It does exactly what you expect.

In Ruby, we use HTTParty.

require 'httparty'

class GithubFetcher
  include HTTParty
  base_uri 'https://api.github.com'

  def self.get_commits(user, repo)
    get("/repos/#{user}/#{repo}/commits")
  end
end

Notice the difference? In Python, requests is a tool we use. In Ruby, HTTParty is a module we include. We are literally extending our class with HTTP capabilities. This is the Object-Oriented nature of Ruby shining through. In Ruby, everything is an object, and classes are open for modification. We aren't just calling a function; we are building an object that knows how to talk to GitHub.

Now we have a list of raw commits. We need to count them by author and find the busiest days.

Python is the king of data because of libraries like Pandas. We don't write loops in Python if we can avoid it. We use DataFrames.

import pandas as pd

def process_commits(commits):
    # Load data into a DataFrame
    df = pd.DataFrame(commits)

    # Normalize the nested JSON to get author names
    df['author_name'] = df['commit'].apply(lambda x: x['author']['name'])

    # Count commits by author
    top_authors = df['author_name'].value_counts().head(5)

    return top_authors.to_dict()

This is incredibly powerful. With three lines of code, I can process millions of rows. However, it is heavy. I had to install a massive library just to count some items. It feels like bringing a tank to a knife fight. It’s effective, but it’s overkill.

Ruby doesn't need Pandas for this. Ruby's standard library has a module called Enumerable, which is legendary.

def process_commits(commits)
  commits
    .map { |c| c['commit']['author']['name'] } # Extract names
    .tally                                     # Count occurrences
    .sort_by { |_, count| -count }             # Sort descending
    .take(5)                                   # Get top 5
    .to_h                                      # Convert back to Hash
end

Look at that Ruby code. .map, .tally, .sort_by, .take. It reads like English instructions. "Map the names, tally them up, sort by count, take the top 5."

I didn't need to install any external libraries. This is built into the language. This is what Ruby fans mean when they say the language makes them happy. You don't search for a library; you just ask the data to transform itself.

Now we need to put this on the web. We are using "Micro-frameworks." These are designed to let you spin up a server in a single file.

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/analyze/<user>/<repo>')
def analyze(user, repo):
    data = get_commits(user, repo)
    return jsonify(data)

Flask uses Decorators. This is a very "Pythonic" concept. We are wrapping our function with metadata that tells the server "When this URL is hit, run this function." It is explicit. You can see exactly what is happening.

Sinatra actually inspired Flask. Let's see how the original does it.

require 'sinatra'
require 'json'

get '/analyze/:user/:repo' do
  content_type :json
  data = get_commits(params[:user], params[:repo])
  data.to_json
end

Sinatra uses a DSL meaning Domain Specific Language. Notice we aren't defining a class or a function in the traditional sense. We are just typing get.

This is Ruby's superpower: Metaprogramming. Ruby allows library authors to change the syntax of the language to fit the domain. In Sinatra, it feels like you aren't writing Ruby; you are writing "HTTP".

However, this magic comes at a cost. If you don't know Sinatra, you might look at this and ask, "Where is the get method defined? Is it a global variable? A method on an object?" It’s implicit. Python's decorators make it obvious that analyze is just a function.

We have built the app in both. But an app doesn't exist in a vacuum. It exists in an ecosystem.

If you choose Python, you have superpowers. You have NumPy for math. PyTorch and TensorFlow for AI. Django for web. Ansible for automation. BeautifulSoup for scraping.

Python is the second-best language for everything. It might not be the fastest, it might not be the prettiest, but if you need to integrate a web app with a Machine Learning model, Python is the only logical choice. The job market is massive. You can work in Web, Data, Ops, Security, or Academic Research.

If you choose Ruby, you really only have one superpower: Web Development.

Ruby is almost synonymous with Ruby on Rails. Rails is a masterpiece. It allows small teams to build massive products like GitHub, Shopify, and Twitch, incredibly fast.

But outside of web dev? Ruby is... quiet. You can use it for scripting, but nobody uses it for AI. Nobody uses it for embedded systems. If you learn Ruby today, you are effectively learning to be a Rails Backend Engineer. That is a lucrative career, but it is a narrower path.

So, is Ruby dead? Absolutely not.

Writing the Ruby version of this project was fun. That’s the only word for it. The code flowed from my fingertips. I didn't have to fight the syntax. I didn't have to look up imports. The Enumerable methods felt like superpowers. If you are a solo developer or a startup founder who wants to build a product fast and enjoy the process, Ruby is still the king of productivity.

But writing the Python version felt like Engineering. It was robust. It was explicit. And I knew that if I wanted to expand this project—say, to use AI to predict future commit activity—I would already be in the right ecosystem.

So, choose Ruby if you value the art of coding. Choose it if you want to build web applications with a framework that respects your time and intelligence. Choose it if you want to fall in love with programming again.

But, choose Python if you value utility. Choose it if you want a tool that can do anything. Choose it if you want to work in Data Science, AI, or if you just want the safest bet for a long career.

If you want to see me compare Go vs Rust or anything else, then let me know in the comments :)

Code Hike in 100 Seconds

Fabian Frank Werner — Sun, 11 Jan 2026 23:00:00 +0000

Code Hike. A remark-able toolkit famous for transforming boring documentation into cinematic masterpieces. It makes your plain README files look like hot garbage by comparison. It’s the secret weapon used to build viral technical tutorials, interactive blog posts, and high-end documentation sites.

It was created in 2021 by Rodrigo Pombo, a developer known for pushing the boundaries of what the web can do. He designed it to bridge the gap between static Markdown and dynamic storytelling, effectively becoming the "Christopher Nolan" of technical writing.

The problem it solves is "wall-of-text" fatigue. Traditionally, if you want to explain complex code, you paste a giant block of text that readers immediately scroll past. Code Hike changes the game by treating code as a first-class citizen. Unlike standard syntax highlighters like Prism or Shiki which just colorize text, Code Hike parses the abstract syntax tree to add focus, motion, and interactivity. It allows you to guide the user's eye through a file line-by-line, creating a "scrollytelling" experience that feels more like a video than a document.

To get started, install the package in a React-based framework like Next.js or Remix, then configure it as a plugin. The magic happens inside MDX files. You write standard markdown code fences, but you enhance them with magic comments.

For example, write a standard JavaScript function, but inside the code block, add the comment // ! focus followed by a range of line numbers. When rendered, Code Hike will spotlight those specific lines and dim the rest, ensuring the reader knows exactly where to look. You can even attach a tooltip directly to a variable (// ! callout), or use the diff feature to animate changes between two versions of a file.

Code Hike works by compiling your markdown into fully customizable React components. This means you can swap out the default styling for your own design system, creating a consistent look across your docs. It supports everything from line numbers and copy buttons to complex tab switching and terminal simulations. Now compile your site with npm run build and watch your engagement metrics hike up that mountain.

An Honest Review of Google Antigravity

Fabian Frank Werner — Sun, 04 Jan 2026 23:00:00 +0000

So, for the last year, if you wanted the best AI coding experience, you were paying $20 a month for Cursor. It’s been the king. But there is a new competitor in the ring. And yes, it’s a VS Code fork. But no, it’s not from some random startup.

It’s from Google.

It’s called Antigravity. And right now, during the preview, it is fully, 100% free. You get access to their newest, models like Gemini 3, full browser orchestration, and an entirely new way to manage code, without swiping a credit card.

Now, usually when Google releases a developer tool, it’s either incredible or it gets killed in six months. I’ve been daily driving Antigravity for the past week, digging into the code, and honestly? It’s a bit of both. It is one of the most promising pieces of software I’ve seen this year, and also, at times, the single most frustrating editor I have ever used.

We need to talk about the "Agent-First" workflow, the crazy Gemini 3 benchmarks, and the fact that this might actually just be a zombie version of another editor called Windsurf. Let’s get into it.

So, first things first. If you peel back the skin, this is VS Code. If you go into the "About" section, you see the VS Code OSS version. But Google has done a lot of work to hide that.

They’ve renamed "VS Code Settings" to just "Editor Settings." They’ve stripped out a lot of the familiar Microsoft branding. And interestingly, if you dig into the file search, you might see references to something called "Cascade."

Now, if you’ve used the Windsurf editor, you know that "Cascade" is the name of their AI agent. So, it looks like Google might have acquired some tech, or some humans, or just forked a build of Windsurf to get this off the ground quickly. It’s a little uncanny valley.

But the biggest change isn't the code under the hood; it's the Three Surfaces.

Google’s thesis is that an IDE shouldn't just be a text editor anymore. It needs to be an operating system for Agents. So you have the Editor, which is where you type. You have the Browser, which is a fully controlled Chrome instance. And most importantly, you have the Agent Manager.

This Agent Manager is the star of the show. It’s literally a separate application window that acts as an "Inbox" for your development tasks.

The idea here is brilliant. Instead of having your AI chat squeezed into a sidebar inside your code, your "Manager" sits outside. It’s Mission Control. You can have five different projects running in parallel. You can see which agents are thinking, which ones are waiting for approval, and which ones have failed. It’s designed for the ADHD developer brain where you are bouncing between tasks.

And when you want to dive in, you just hit Command+E, and it focuses the Editor for that specific project. It feels like a futuristic workflow... when it works. But we’ll get to the bugs in a minute. First, I want to show you what this thing can actually do when you give it a real challenge.

Antigravity is built around Gemini 3 and Gemini 2.5. And since this is free right now, I decided to push it hard. I asked it to build a clone of that old "Insaniquarium" game—a simulation where you drop food, fish eat it, and they drop coins.

I tried this same prompt with other high-end models like Codex High. I spent an hour fighting it. It couldn't handle the physics. The particles were broken. It burned through 3.5 million tokens and gave me a broken mess where the fish were 2D sprites floating in a void.

Then I gave the exact same prompt to Antigravity with Gemini 3.

It one-shot it. First try. It built a working game using Phaser. But here is the crazy part—it didn't just write the code. It generated the assets.

I didn't give it images of fish or coins. The Agent realized, "Hey, I need sprites for this," so it paused, used its internal image generation model to create the fish, the food, and the background, and then injected them into the game code.

Now, were they perfect? Of course not. The first time, the fish had white backgrounds instead of transparent ones, so they looked like JPEGs floating around. But I told the Agent, "Fix the transparency," and it went back, regenerated the assets, and updated the code.

This is that "Agent-First" distinction. It’s not just a chatbot. It’s a worker that has access to tools—an image generator, a file system, a browser. It felt like I was directing a junior developer who also happened to be a graphic designer.

The other killer feature here is the Browser integration. Google makes Chrome, Google makes Antigravity, so naturally, they talk to each other.

You can spin up a "Browser Agent" to test your work. You tell it, "Go to localhost and test the game." A Chrome window opens with this blue "Agent Control" border. You watch the red dot—which is the AI's cursor—move around, click the fish, drop food, and verify the physics.

It even records a video of itself doing it, so you can watch the playback later in the "Walkthrough" artifact. It captures screenshots of errors. It’s just incredibly cool to watch.

But—and there is always a but—it’s buggy. Half the time, I’d get a "Controls Disabled" warning even though it was working. Sometimes it would try to connect to the wrong localhost port because I had too many projects open. It’s powerful, but it feels like a prototype.

And that brings us to the reality of using Antigravity right now. As impressive as the model is, the editor itself... got some issues.

First off, it’s buggy. I’ve had buttons just stop working. I’ve had the sidebar icons vanish until I clicked them blindly. The Svelte extension—one of the most popular web frameworks—just straight up doesn't work. It breaks the whole editor.

Then there is the "Review Code" button. You see a button that says "Review Changes," so you click it, right?

It instantly closes. It’s almost like the editor is trolling you. We joked that you just aren't in the "Agentic Mindset" yet. You don't review the code when you want to; you review it when the Agent tells you it's ready.

There are also weird missing features. For example, arrow keys.

In the file explorer, you can’t use the arrow keys to move up and down. You have to click. In a code editor. That is a crime.

And for the power users: No Git Worktrees. Cursor has this, and it’s amazing for switching branches instantly. Antigravity doesn't support it yet, which is ironic because the whole point of the Agent Manager is multitasking.

We also have to talk about efficiency. This app is heavy.

I noticed significant battery drain on my MacBook Pro while running this. There is also this fancy glow effect around the UI when the Agent is thinking. It looks cool, but it causes input lag. When I’m typing in the editor while the Agent is generating, I can literally feel the delay.

And that’s the trade-off. You are running a local Chrome instance, a heavy Electron app, and constant streaming connections to Gemini. It eats resources for breakfast.

So, where does that leave us?

Google Antigravity is a fascinating, frustrating, yet futuristic mess.

The Agent Manager workflow—that "Inbox" for your code—is genuinely a great idea. I hope every other editor copies that. The Gemini 3 model is shockingly good at one-shotting complex tasks and generating assets. And the price? Well you can't beat free.

Google says the free tier limits reset every five hours, and honestly, I hit those limits a few times, but for most people, it’s plenty. You are getting access to state-of-the-art models without a subscription.

But would I uninstall Cursor for this? Not today. The bugs, the missing syntax highlighting in some modes, the broken extensions—it’s just not stable enough for a deadline.

However, this is just the preview. If Google actually commits to this—if they fix the bugs, bring in the full extension support, and keep the Agent Manager workflow—this could be the one.

For now, I recommend you download it. Use it for your side projects. Play with the aquarium game generator. It’s a glimpse into a future where we do less typing and more managing. And that future looks pretty bright right now... assuming you can get the arrow keys to work.

Are you trusting Google with your code, or are you sticking with VS Code, Cursor, or whatever?

JavaScript vs TypeScript - I built the same crypto tracker with both

Fabian Frank Werner — Sat, 27 Dec 2025 23:00:00 +0000

If you are building a web application today, there are two heavyweights competing for your attention. In the red corner, we have JavaScript—the king of the web; and in the blue corner, we have TypeScript—the challenger from Microsoft.

Both tools achieve the same fundamental goal: they make things happen in a browser. But there is a world of difference in the developer experience. No matter which one you choose, the other one automatically becomes your arch-nemesis. Because you don’t choose anything but the absolute best technology out there.

To figure out which one is best, I built the exact same Real-Time Crypto Tracker with both JavaScript and TypeScript.

In this post, we are going to dive into a detailed side-by-side comparison of the features, tooling, ecosystem, performance, and of course, the code! By the end of this post, you will know exactly which one fits best in your ideology.

But this isn't a line-by-line coding tutorial. If you want to learn how to build these apps from scratch, subscribe to my free newsletter.

Let’s start by comparing the setup and the "Barrier to Entry."

Setup

To get started, we are using Vite. Why Vite? Because create-react-app is dead, and we don't mourn the dead here; we move on to faster tools.

For JavaScript, I run npm create vite@latest crypto-tracker-js -- --template react.

For TypeScript, it’s npm create vite@latest crypto-tracker-ts -- --template react-ts.

Both are blazingly fast. Vite doesn't care about your feelings or your language preference; it just scaffolds the project instantly. But as soon as we open the projects in VS Code, the difference slaps you in the face.

In the JavaScript project, you have your package.json, your vite.config.js, and your source files ending in .jsx. It feels lightweight. You can almost hear the wind whistling through the empty space where configuration files usually live. It invites you to just start coding.

Now, look at the TypeScript project. You see .tsx files, which is fine, but then you see tsconfig.json and tsconfig.node.json.

This file is the constitution of your project. It dictates the laws of your universe. In JavaScript, the laws are "whatever works." In TypeScript, you have to explicitly tell the compiler how strict you want to be. Do you want to allow implicit any types? Do you want to check for unused local variables? Do you want to strictly check for nulls?

For a beginner, this file is a wall of JSON that screams "Configuration Hell." You have to understand what a "target" is and how module resolution works before you even write "Hello World." For a senior engineer, however, this file is a safety blanket. It guarantees that every developer on the team is playing by the same rules.

Structure

The core difference between these two isn't just syntax; it's when you catch your mistakes. JavaScript is dynamically typed, which means variables can be anything at any time. TypeScript is statically typed, meaning once a variable is a number, it dies a number.

Let's look at the Coin component. We are fetching a list of crypto coins from an API.

const CoinRow = ({ coin }) => {
  return (
    <div className="row">
      <img src={coin.image} />
      <span>{coin.name}</span>
      <span>${coin.current_price}</span>
    </div>
  );
};

In JavaScript, I write a component that takes a prop called data.

This looks innocent. But as I'm typing coin.current_price, I am relying entirely on my own memory. I have to keep the API documentation open on a second monitor. Is it current_price or currentPrice? Is image a string URL or an object containing sizes?

If I type coin.price instead of coin.current_price, the editor doesn't care. It saves the file. I run the app. The browser renders an empty span. I spend 15 minutes console logging coin to figure out why the price is missing. This is the "Guess and Check" loop, and it burns hours of your life.

export interface Coin {
  id: string;
  symbol: string;
  name: string;
  image: string;
  current_price: number;
  high_24h: number;
  low_24h: number;
}

Now, watch the TypeScript workflow. Before I even think about the UI, I have to define the shape of my data. This is mental overhead. I have to stop, look at the API response, and translate it into an Interface.

import type { Coin } from './types';

interface Props {
  coin: Coin;
}

const CoinRow = ({ coin }: Props) => {
  return (
    <div className="row">
       {/* The moment I type "coin.", a dropdown appears */}
       <span>{coin.current_price}</span>
    </div>
  );
};

The editor knows what a coin is. If I try to access coin.price, the text turns red immediately. "Property 'price' does not exist on type 'Coin'."

This is the killer feature. I am not coding in the dark anymore. The IDE is my pair programmer, constantly whispering the correct property names in my ear. It turns the documentation into code that lives right under your cursor.

Data

export const fetchCoins = async () => {
  const res = await fetch('https://api.coingecko.com/...');
  return res.json();
};

Let's dial up the complexity. We need to fetch this data from the internet. This introduces asynchronous code and the concept of "Generics."

In JavaScript, our fetch function is simple, but dangerous.

The return value of this function is a Promise that resolves to... any. It could be an object, an array, a string, or an error message. We don't know, and JavaScript doesn't care. When we consume this function in our React component, we are flying blind.

export const fetchData = async <T>(url: string): Promise<T> => {
  const res = await fetch(url);
  if (!res.ok) {
      throw new Error('Network response was not ok');
  }
  const data = await res.json();
  return data as T;
};

In TypeScript, we want to tell the consumer of this function exactly what they are getting back. This is where we use Generics.

This generic <T> allows us to use this one fetch function for Coins, for User profiles, for anything, while maintaining strict typing.

However, there is a dirty secret here. Look at return data as T. That as keyword is a lie. We are lying to the compiler. We are saying, "I promise this JSON from the internet matches my Interface."

But what if the API changes? What if the internet goes down? TypeScript checks your code at compile time, not runtime. If the API sends back a price as a string instead of a number, TypeScript won't catch it, and your app might still crash.

To truly fix this, you would need a runtime validation library like Zod. With Zod, you define a schema that validates the data as it comes in, effectively bridging the gap between the static world of TypeScript and the chaotic world of runtime JavaScript. But that adds bundle size and complexity, which is the constant trade-off you make in this ecosystem.

Trap

Now let’s look at how we store this data in React state.

const [coins, setCoins] = useState([]);

In JavaScript, it’s simple. coins is an array. I can push numbers into it, strings, objects, or even null.

const [coins, setCoins] = useState<Coin[]>([]);

In TypeScript, inference usually works well, but sometimes we need to be explicit:

Now, if I try to setCoins(['bitcoin']), TypeScript yells at me because a string is not a Coin object. This prevents state contamination, where you accidentally store the wrong data type and break your app five steps down the line.

But here is where developers get lazy. Sometimes, TypeScript is screaming at you because your types are complex. You just want it to shut up so you can test your feature. So you do the forbidden thing.

const [data, setData] = useState<any>([]);

The any type essentially turns off TypeScript for that specific variable. It is a trap. Once you use any, it spreads like a virus. If you pass that any variable to another function, that function now accepts anything. You have successfully defeated the entire purpose of using TypeScript in the first place.

Using any is like wearing a seatbelt made of paper. It looks like safety, but it won't save you when you crash.

Refactoring

If there is one reason to switch to TypeScript, it is this: Refactoring.

Let's say our project manager decides that image is a bad name for the property. We need to rename it to imageUrl across the entire application.

In the JavaScript project, this is a nightmare scenario. I have to use "Find and Replace." I search for "image".

The search results include:

The actual property in the API response.
A CSS class named .coin-image.
A comment in the README.
A variable in a totally unrelated file.

I have to manually check every single instance. If I miss one, the image breaks. If I change the wrong one, the CSS breaks. It is anxiety-inducing.

In TypeScript, I go to my Interface.

I put my cursor on image. I press F2 to Rename. I type imageUrl and hit Enter.

VS Code analyzes the dependency graph. It knows exactly which references refer to this specific property on the Coininterface. It ignores the CSS classes. It ignores the comments. It updates the API call, the Prop types, and the Component usage in one second.

I save the file, and I have 100% confidence that I didn't break anything. This feeling of safety allows you to iterate faster. You aren't afraid to change your code because the compiler has your back.

Performance

Finally, let’s talk about performance. There is a misconception that TypeScript is slower because it has to compile.

Here is the reality: Browsers cannot run TypeScript. They only understand JavaScript. This means your TypeScript code must be erased before it ever reaches the user.

Vite handles this using esbuild. It’s incredibly fast because during development, it doesn't actually check your types. It just strips them out so the browser can run the code. This means your dev server starts almost as fast as a plain JS project.

However, for the production build, we run tsc (the TypeScript Compiler). This checks every single line of code for type errors. If there is a single error, the build fails.

This is a feature, not a bug. It prevents you from shipping broken code to production. In JavaScript, that error would have made it to the user's browser and crashed their session. In TypeScript, it crashes your build server, forcing you to fix it.

So, does TypeScript make your app faster? No. The runtime performance is identical. But does it make your development cycle faster? Over the long run, absolutely.

Verdict

So, after building this tracker twice, here is the verdict.

JavaScript is the wild, fun friend who invites you to a rave at 2 AM. It’s great for hackathons, small prototypes, and solo projects where you just want to move fast and break things. It feels fluid, unrestricted, and creative. If I have an idea I want to validate in an afternoon, I might still reach for JavaScript.

TypeScript, however, is the responsible architect. It demands a blueprint before you lay the first brick. At first, it feels restrictive. You spend time writing Interfaces instead of features. You fight with the configuration. You curse the compiler.

But as the project grows—as you add more files, more complex data structures, and more team members—TypeScript becomes the only thing keeping your sanity intact. The ability to refactor instantly, the elimination of entire classes of bugs, and the self-documenting nature of the code make it the superior choice for any serious application.

If you are looking to get hired in the industry today, TypeScript is not optional. It has won the war for attention.

So, stick with JavaScript if you want to feel like a cowboy. But learn TypeScript if you want to be an engineer.

If you want to see me suffer through building another app in the two programming languages or frameworks of your choice, then hit that subscribe button and let me know in the comments. Thanks for watching, and I will see you in the next one.

CSS vs Tailwind CSS - I built the same home page with both

Fabian Frank Werner — Fri, 19 Dec 2025 11:36:07 +0000

If you go to any social media right now, I promise you will find developers screaming at each other about CSS.

On one side, you have the Purists. They believe in the sanctity of semantic HTML, the Separation of Concerns, and the "Cascading" nature of style sheets.

On the other side, you have the Pragmatists. The Tailwind cult. They believe that naming classes is a waste of time and that CSS is better when it looks like a crossword puzzle that exploded in your HTML.

But arguments are cheap. Code is real. So, to actually understand the difference, I built the exact same project with both. We are recreating the Google Dark Mode homepage. It looks simple—a logo, a search bar, a footer—but it’s actually a perfect stress test for layout systems, theming, and component architecture.

We aren't doing a "Winner takes all" battle today. We are going to dissect the experience of building this. We’ll look at the setup, the mental models, the ugly parts of the code, and finally, a file-size comparison that actually shocked me. By the end, you’ll know exactly why you should pick one over the other. Let's get into it.

Chapter 1: The Setup

Let’s start with the setup. This is where the first philosophical divide happens.

With Vanilla CSS, the "stack" is non-existent. You create a file. You link it. You write code. There is zero friction. You are writing the language the browser actually understands.

Tailwind, however, brings the baggage. You need Node.js. You’re initializing a config file. You’re setting up a build process to watch your files. For a single HTML page like this, Tailwind feels like bringing a construction crane to build a Lego set.

But—and this is a big but—once that crane is set up, the speed changes. In Vanilla CSS, you are working in the Global Scope. The "Cascade" is powerful, but it's also dangerous. If I define a generic button class, it affects every button on the site.

Tailwind doesn't rely on the cascade. It relies on a System. And that system starts with configuration.

Chapter 2: The Reset

But before we draw a single pixel, we have to talk about the "Reset." This is Step 0, and it catches almost everyone off guard.

In standard CSS, the browser uses a default box model where adding padding increases the width of the element. If you have a 100px box and add 20px of padding, it becomes 140px wide. It makes layout math a nightmare.

So, in my Vanilla CSS version, the very first thing I have to do is manually tell the browser: "Stop trying to help me." border-box ensures that if I say a box is 100px, it stays 100px, even if I stuff it with padding.

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

In Tailwind, I didn't write a single line of reset code. Why? Because Tailwind injects a system called "Preflight" automatically. It flattens the browser styles, applies border-boxglobally, and removes all default margins. It gives you a truly blank canvas. In Vanilla CSS, you have to build that canvas yourself.

Chapter 3: The Colors

Now, let's talk about Theming. We need to match Google's specific dark mode grays.

In my Vanilla CSS build, I use CSS Variables.

:root {
  --bg-primary: #1f1f1f;
  --bg-element: #303134;
  --link-color: #8ab4f8;
}

This is clean. It’s dynamic. If I change --bg-primary to red in the DevTools, the whole site updates instantly. But, there are no guardrails. As a developer, I can easily break the design system. So the CSS file allows me to be sloppy.

In Tailwind, I have to be more disciplined. I open tailwind.config.js and extend the theme.

colors: {
  google: {
    bg: "#1f1f1f",
    element: "#303134",
    // ...
  }
}

This config file acts as a "Contract." When I go to my HTML, IntelliSense kicks in. If I type bg-goo..., it suggests bg-google-bg. It prevents "Magic Numbers." You aren't just painting pixels; you are referencing a system. For large teams, this is the difference between a consistent UI and a messy one.

Chapter 4: The Layout

Now, let's look at the actual layout code. This is where we see the concept of "Context Switching."

In Vanilla CSS, I have this markup (<div class="nav-right">) that reads like English. But as a developer, I don't know what .nav-right does. Is it a grid? Is it absolute positioning? To find out, I have to switch tabs to style.css and find the class.

.nav-right {
  display: flex;
  align-items: center;
}

Okay, so this is Flexbox. We are aligning the items along the cross-axis. In Vanilla CSS, the structure and the layout logic CSS are physically separated. You have to hold the connection in your head.

Now look at Tailwind. <div class="nav-right flex items-center gap-4"> I admit, it looks "noisy." But look at gap-4. In the old days of CSS, spacing items was hard. We used margin-right on everything except the last child. Tailwind exposes the modern CSS gap property as a utility. gap-4 puts 1rem of space between every child. I can visualize exactly how this component behaves just by reading the class string. This is "Locality of Behavior." I am styling the element while I build it.

Chapter 5: The Problem

Now, I hear the Backend Developers screaming at the screen: "But what if I have a button? Do I have to copy-paste bg-blue-500 text-white rounded px-4 py-2 on every single button? That violates DRY principles!" I hear you! Now, this is the "Google Search" buttons. We have two of them.

In my Tailwind HTML, yes, it looks repetitive.

<button class="bg-google-element hover:border-gray-500 ...">Google Search</button>
<button class="bg-google-element hover:border-gray-500 ...">I'm Feeling Lucky</button>

If I want to change the padding on both, I have to edit two places. This sucks.

But Tailwind has a solution for this called @apply. If you really want to clean this up, you can go to your input CSS file and do this:

.btn-google {
  @apply bg-google-element text-google-textMain px-4 py-2 rounded hover:border-gray-500;
}

Now, in your HTML, you just use class="btn-google". So you can use classes in Tailwind. But usually, you shouldn't. In modern development (like with React, Vue, Svelte), you wouldn't make a CSS class. You would make a Component. You’d make a <Button /> component that holds these styles internally. Therefore Tailwind works best when paired with a component framework, not just raw HTML.

Chapter 6: The Specifics

Let's get technical. The Search Bar is the most complex component because it has specific pixel dimensions and hover states.

In CSS, I handle the hover state using a Pseudo-class.

.search-container:hover {
  background-color: var(--bg-element-hover);
  box-shadow: 0 1px 6px 0 rgba(23, 23, 23, 0.5);
}

This relies on Specificity. The browser calculates that this rule is more specific than the base rule, so it applies it.

In Tailwind, we do this inline. And this is where we see a feature called Arbitrary Values. Look at this class: h-[46px]. And this one: shadow-[0_1px_6px_0_rgba(23,23,23,0.5)]. Tailwind haters love to point at this and say, "See! That's ugly!"

And yeah, it is ugly. But it’s also incredibly powerful. I needed a 46px height to match the Google reference. I didn't have to create a new class or add an inline style attribute. I just told the Tailwind Just-In-Time compiler: "Hey, make me a class for 46 pixels." And it did. I didn't have to worry about specificity wars or overriding other styles. It just works.

Chapter 7: The Compiler

Speaking of the compiler, let's get "Under the Hood." How does Tailwind actually work? When I type a class like h-[46px] for the search bar, what is happening?

Tailwind is not a static CSS file. It is a program written in JavaScript. When you save your HTML file, the Tailwind "Just-In-Time" (JIT) compiler scans your code. It uses Regular Expressions (Regex) to look for class names. It sees h-[46px]. It parses that string, realizes you want a height of 46 pixels, and generates a CSS rule on the fly: .h-\[46px\] { height: 46px; }

This is why you can leave your CSS file empty. The compiler is writing the CSS for you, based on what you asked for in the HTML. It also handles Specificity for you. In Vanilla CSS, if I have an ID and a class, they fight. In Tailwind, because everything is a utility class, everything has the same "weight." You rarely run into those moments where you write a style and nothing changes because some hidden rule is overriding it.

Chapter 8: The Paradox

Okay, we have two identical looking websites now. But what are we shipping to the user? We always hear that "Tailwind is small." So I ran the build, and here are the results…

Vanilla CSS: 5 KB. Tailwind Output: 16 KB.

Wait. The "optimized" tool is 300% larger? Yes, and here is the nuance. Tailwind's 16KB includes that "Preflight" reset we talked about in Chapter 2. It’s a reset sheet that normalizes all the browser quirks so your site looks the same on Chrome and Safari. That’s a base cost. Vanilla CSS is "Pay for what you use." I only wrote the lines I needed, so it’s tiny.

However, this is a single page. If I added 50 more pages to this app... The Vanilla CSS file would grow Linearly. Every new page means new classes. The Tailwind file would flatten out (Logarithmic). Why? Because I’m reusing flex, items-center, and text-white everywhere. So while Vanilla wins the sprint, Tailwind wins the marathon.

Chapter 9: The Verdict

So, which one should you choose?

If you are a beginner, look me in the eyes: Do not start with Tailwind. You need to feel the pain of the Box Model. You need to understand how Flexbox axes work. You need to understand position: relative vs absolute. If you jump straight to Tailwind, you are learning a framework, not the web.

But, if you are building a real product, a dashboard, or working on a team? Tailwind CSS has won me over. The "ugliness" of the HTML is a small price to pay for the development speed. It allows you to come back to a project 6 months later and know exactly what is happening without hunting through a 5,000-line stylesheet.

And if you want to see me compare React vs Svelte or something else entirely, let me know in the comments. Don't forget to cursor: pointer that like button. See you in the next one.

OpenAI's Browser is here… and 7 more things that shipped this week

Fabian Frank Werner — Fri, 31 Oct 2025 12:35:26 +0000

It’s time for another round of tech news.

OpenAI released Atlas.

A full-fledged web browser that bakes ChatGPT right into the interface.

It’s designed to let you browse, search, and summarize pages inside the same window, powered by GPT-4o-mini.

Imagine Chrome, but every tab comes with its own assistant.

It’s Mac-only for now, with Windows coming later, and yes, it uses Chromium under the hood.

But not everything’s shiny — early testers already found that the browser might be more vulnerable than Chrome or Edge because of how its sandboxing works.

So yeah, it’s cool… but maybe don’t log into your bank account just yet.

Next, React Native 0.82.

After seven years of work — yes, seven — the React Native team has finally shipped the New Architecture.

It’s a total rebuild of how React Native talks to your phone’s native layer.

Gone is the old JSON bridge that caused delays and random jank.

Now, JavaScript and native code communicate directly through a new C++ API.

You also get concurrent rendering and an event loop that can handle multiple priorities, meaning smoother UIs and fewer dropped frames.

And there’s a new version of the Hermes engine, with huge performance gains.

Then there’s Next.js 16.

This version makes Turbopack the default bundler, adds new caching APIs, and integrates seamlessly with the React Compiler.

It’s faster, leaner, and breaks just enough things to remind you it’s still JavaScript.

And speaking of JavaScript, Node… version 25 came out.

It ships with the V8 14.1 engine, faster JSON.stringify, built-in base64 helpers, and safer defaults for networking.

Not as flashy as Bun, but this is the foundation most of the web still runs on — so those boring updates matter.

Now, let’s talk about the new kid on the block — Vite+.

The team behind Vite, Vitest, and Rolldown announced Vite Plus — a unified toolchain that does everything:

develop, build, test, lint, and even visualize your project, all from one CLI written in Rust.

So instead of duct-taping five tools together, you just run vite new.

It’s still source-available and free for individuals, but the premium features will help fund the ecosystem.

Honestly, I love this move — finally an open-source company that wants to make money without turning into another cloud platform.

In framework news, Astro 5.15 dropped with smarter font preloads and deployment fixes.

Solito 5 brings better support for hybrid Next + React Native apps.

Biome 2.3 improves linting speed and stability.

And the Hono CLI now scaffolds full-stack apps in seconds.

Cursor 2 also launched this week, and it’s not just an editor update.

It’s trying to become the AI IDE — think Copilot, but deeply integrated into your entire workflow.

You can ask questions, refactor code, and spin up full projects without leaving your editor.

And then there’s Workflow.

It’s a new TypeScript toolkit that makes your async code durable.

Basically, you can take any regular async function, add "use workflow", and it suddenly becomes reliable, resumable, and observable — no queues, no YAML, no ops nightmares.

Think of it as “reliability-as-code.” You write normal TypeScript, and Workflow handles retries, state persistence, and tracing automatically.

You can even pause for days or months, come back, and pick up right where you left off — perfect for long-running jobs or AI agents that need memory.

There’s built-in observability too, so you can replay, debug, and time-travel through your workflow runs.

It works locally, in Docker, or on Vercel — totally open source and portable.

That’s all for this week...

10 Dead Programming Languages

Fabian Frank Werner — Wed, 15 Oct 2025 22:00:14 +0000

Forget your toy languages, such as Python and JavaScript.

We’re grave robbing ten programming languages that have been dead for decades.

Like COBOL, which was born in 1960 when the US Department of Defense decided business software should all speak one language. The result? A committee-approved monstrosity designed to manage payroll, inventory, and crush the souls of programmers.

At a time when FORTRAN and ALGOL only had arrays, it introduced record data structures—the precursor to structs.

It died because academia hated it; it was massive and slow, and no one wanted to build on top of it.

Yet, COBOL still runs a shocking amount of global finance, insurance, and government systems. Your bank statement probably comes from a “dead” language older than your parents.

ALGOL, released in 1960, was supposed to be pseudocode you could actually run. And it invented half of modern programming: lexical scoping, structured programming, nested functions, formal specs, block comments—the works.

It’s the reason most modern languages look the way they do. C? Java? JavaScript? All ALGOL descendants.

It died because they forgot to include I/O. You couldn’t use it for… you know… anything practical.

Instead, people made “ALGOL-like” languages with actual features—like BCPL, which inspired C, which inspired everything else. ALGOL’s kids buried it alive.

APL came out in 1962 and looked like someone spilled a math textbook on your keyboard.

Seriously—you needed a special keyboard just to type it. But under the cryptic symbols was a revolutionary idea: array programming. No more looping through lists—just tell the computer to operate on the whole thing at once.

APL’s DNA runs through R, NumPy, pandas, MATLAB, and most of modern data science.

It died because of the keyboard, for one. Also, it only worked well with homogeneous data, so no fancy dataframes.

BASIC arrived in 1964 to make computers accessible to “non-engineers”, meaning kids, hobbyists, and small businesses.

One the 1970s microcomputers it was the language—you could cram a BASIC interpreter into just 2 KB of RAM.

BASIC gave us real-time interpreters and an entire generation of self-taught programmers. Eventually, it evolved into Visual Basic, the language behind countless Office macros.

It died, because people looked down on it as a “toy” language. Once cheap hardware could run C, BASIC was pushed aside.

In 1966, IBM tried to merge FORTRAN and COBOL into a single “super language” for both science and business. They created PL/I—the Swiss Army knife of the 60s.

It had structured types before C, pointers before C, constants, function overloading—you name it.

It died because everyone hated it for different reasons. FORTRAN people thought it was too COBOL-like, COBOL people thought it was too FORTRAN-like, and everyone else thought IBM was trying to lock them in.

SIMULA 67, born in Norway, started as a simulation language but became the first real object-oriented programming language—complete with classes, subclassing, virtual methods, and protected attributes.

It inspired C++, CLU, ML, and basically every OOP textbook ever written.

It died because it was painfully slow. Like, “hope you’re running on a mainframe” slow. People stole its ideas and reimplemented them in faster, more practical languages.

Niklaus Wirth created Pascal in 1970 as a clean, simple alternative to the overly complicated ALGOL-68. It became the teaching language of the 70s and 80s—structured, readable, and widely adopted in universities.

It died, because it just… slowly faded. C became cooler, Java took over academia, and Pascal became that nice guy you remember fondly but never call.

CLU, from 1975, was basically the hipster of programming languages—full of ideas no one appreciated until decades later: abstract data types, iterators, generics, checked exceptions.

It died because no one cared about its concepts at the time; therefore, CLU quietly slipped into history.

ML started in 1976 as the language for the LCF proof assistant. It introduced type inference, meaning you didn’t have to write out all your types—the compiler just knew.

It also championed typed functional programming, algebraic data types, and modularity.

It died, because it stayed niche. By the time Standard ML arrived, Haskell was stealing the functional programming spotlight. Its descendants live on in OCaml and F#.

Smalltalk evolved from 1972 to 1980 and was the first language to make everything an object.

It defined much of how we think about OOP and directly inspired modern IDEs and UI frameworks.

It died because of the “Javapocalypse.” In the 90s, Java stormed in with its C-like syntax, better C interop, and massive corporate backing.

But actually, none of these languages is truly gone. Their DNA is everywhere—in the languages you use today!

[Boost]

Fabian Frank Werner — Mon, 11 Aug 2025 19:33:01 +0000

Fabian Frank Werner

Aug 7 '25

How to ACTUALLY learn JavaScript... A roadmap for beginners

#webdev #javascript #beginners #learning

Comments 8

5 min read

Inner Join vs Left Join vs Right Join vs Full Join

Fabian Frank Werner — Mon, 11 Aug 2025 09:57:00 +0000

You might’ve heard terms like inner join, left join, or full outer join thrown around like confetti at an SQL data party.

And if you’re anything like me when I first heard them…

You nodded along while secretly wondering if these were moves from a ballroom dance class.

So let’s break them down — clearly, visually, and with as little jargon as possible!

We’ll focus on the Big Four: INNER, LEFT, RIGHT, and FULL joins.

By the end of this post, you'll know exactly which one to reach for and when.

And we’ll even sprinkle in the fancy joins for bonus street cred.

But first… What’s a Join?

Imagine two tables at a party.

Table A: A list of customers.

Table B: A list of orders.

Each table knows its stuff—but they’re socially awkward and don’t talk to each other unless you explicitly tell them to.

That’s what a join does: it introduces one table to another using a common key (usually an ID).

So, SQL joins let you combine rows from two (or more) tables based on a related column.

Sounds simple? Good. Let’s get messy.

Inner Join

If SQL joins were a Venn diagram, the INNER JOIN would be the part where the two circles overlap.

SELECT *
FROM customers
INNER JOIN orders
ON customers.id = orders.customer_id;

This says: “Hey database, give me everyone who exists in both the customers and orders table.” So, if someone placed an order, they show up. If they haven’t? Tough luck—they’re not invited to this query party.

It’s clean. It’s efficient. It’s what most people use by default because it filters out the data that doesn’t match on both sides.

Use it when:

✅ You only care about matches in both tables.

Left Join

Now, the LEFT JOIN is like a teacher who wants to make sure every student in their class gets called on—even if some don’t have answers.

SELECT *
FROM customers
LEFT JOIN orders
ON customers.id = orders.customer_id;

This says: “Give me all customers, and show their orders if they have any.” If a customer exists but hasn’t placed an order, they’ll still be in the results—with NULL in the columns from the orders table.

Use it when:

✅ You care about everyone in the left table (usually your main dataset).

✅ You want to see who’s missing data on the other side.

Right Join

RIGHT JOIN is the LEFT JOIN’s mirror twin. It’s clingy to the right table instead.

SELECT *
FROM customers
RIGHT JOIN orders
ON customers.id = orders.customer_id;

This says: “Give me all orders, and show the customer info if it exists.” This can be helpful in rare cases where the right table is the primary one you care about.

Use it when:

✅ You care more about the second table than the first.

Honestly? You can do everything RIGHT JOIN does with a LEFT JOIN if you just flip the table order. So use it if you must—but only if you enjoy chaos.

Full Join

The FULL OUTER JOIN is the SQL equivalent of Oprah giving out participation medals.

SELECT *
FROM customers
FULL OUTER JOIN orders
ON customers.id = orders.customer_id;

This says: “Give me all customers AND all orders—even if there’s no match between them.”

It includes:

Customers with orders ✅
Orders with customers ✅
Customers without orders ✅
Orders without customers ✅

The unmatched rows will have NULL values on whichever side didn’t find a match.

Use it when:

✅ You don’t want to miss anything.

✅ You’re doing audits, reconciliations, or just being overly inclusive.

Here’s how it looks in diagram brain terms:

INNER JOIN = Middle only
LEFT JOIN = Left + middle
RIGHT JOIN = Right + middle
FULL OUTER JOIN = Everything

And if you ever forget which is which, imagine two overlapping pizza slices and ask: “How much pizza do I want?” The answer determines the join, I guess…

Now, if you’ve mastered the basics and want to look smarter at your SQL database parties, here are a few fancier Joins to casually drop into conversation:

The Self Join

When a table joins itself—great for hierarchical data like org charts.

SELECT a.name, b.name AS manager
FROM employees a
JOIN employees b
ON a.manager_id = b.id;

The Cross Join

Every row from one table joins with every row from the other. Usually results in a Cartesian explosion. This is great for permutations, terrible for performance.

SELECT *
FROM sizes
CROSS JOIN colors;

The Natural Join

SQL tries to guess the join condition for you. Which sounds nice... until it guesses wrong!

And always test your joins with real data to make sure you're not accidentally excluding or duplicating anything.

How to ACTUALLY learn JavaScript... A roadmap for beginners

Fabian Frank Werner — Thu, 07 Aug 2025 10:17:00 +0000

An excellent salary, back problems, and social isolation…

If that sounds good to you, I recommend learning the JavaScript programming language.

Learning to code was the best investment in my life.

And it cost me approximately $0, thanks to all the free resources available on the internet.

But how does one learn JavaScript as a complete beginner?

Luckily, you don’t need to be very smart, but you do need to work very hard. And put in the hours required to learn JavaScript as a usable skill.

But hours doing what exactly? Where do I even start?

Sadly, there is no guaranteed step-by-step program, but luckily, there is this post giving you a beginner roadmap to learn JavaScript step by step.

I’m going to blitz through the key JavaScript topics…

Giving you a big‑picture overview and the right order to tackle them later in your own self‑guided deep dive.

What is JavaScript?

JavaScript is the language that powers everything from flashy websites to full‑blown server apps, and occasionally, your late‑night debugging-induced existential crisis. It’s the only programming language that works in every browser, meaning if you’ve clicked, scrolled, or been annoyed by a pop‑up, you’ve met JavaScript.

A Brief (and Weird) History of JavaScript

JavaScript has been through more name changes than a wannabe pop star. It started as Mocha, then got rebranded to LiveScript, before Netscape slapped on “JavaScript” to ride the hype wave of Java… which is ironic, because JavaScript and Java have about as much in common as hamsters and ham radios.

How to Run JavaScript

Want to run JavaScript? Easy. Stick it in a <script> tag in your HTML, type it straight into the browser console, or—if you like your code without a browser babysitter—fire it up in Node.js. There are fancier ways, but this will get you from “I have code” to “look, it runs!” in seconds.

Scopes (a.k.a. Where Your Variables Live and Die)

Variables are just boxes for storing values, and in JavaScript, where you declare them determines who can see them. There’s global scope (everyone can see it), local scope (only certain parts can), function scope, and block scope. Before 2015, we only had var, which was… fine, but also cursed. Then let and const showed up, giving us sane block scoping and making var the VHS tape of JavaScript—still playable, but why would you?

Datatypes

JavaScript has seven primitive datatypes—Number, BigInt, String, Boolean, Null, Undefined, and Symbol. Everything else? Objects. Arrays? Objects. Functions? Objects. Your hopes and dreams? …Still objects. You can check a variable’s type with typeof, but beware: typeof null says “object” because JavaScript likes to keep some of its weird 1995 quirks alive.

Implicit Type Casting (a.k.a. “JavaScript Will Guess for You”)

JavaScript loves to “help” by converting types behind your back. Sometimes it’s convenient, sometimes it’s a horror show. 1 + '1'? That’s '11'. 1 - '1'? That’s 0. Why? Don’t ask. This is one reason TypeScript exists: to stop JavaScript from playing guessing games with your data.

Keyed Collections

Beyond plain objects, JavaScript has Map, WeakMap, Set, and WeakSet. Maps let you store key/value pairs with any type of key. Sets are just unique collections of values. The “weak” versions? They don’t prevent garbage collection, so they’re good for memory‑sensitive data you don’t want hanging around forever.

JSON

JSON — Not a person. Not a typo. It stands for JavaScript Object Notation and is a lightweight data format for sending info between computers. It’s just strings that look like objects, and it’s everywhere: APIs, configs, and anything that needs to speak “structured text.”

Value Comparison Operators

JavaScript gives you == (equality) and === (strict equality). == will happily convert types before comparing, which can lead to “fun” surprises. === does a strict check for both value and type—generally the safer choice. Then there’s Object.is(), which is even stricter, because of course, we needed three ways to compare values.

Loops and Iterations

If you need to repeat something, you’ve got for, while, do...while, for...in, for...of, plus break to stop early and continue to skip steps. If your brain doesn’t hurt after learning them all, congratulations—you’re ready to write JavaScript that confuses future you.

Conditional Statements

If you need your code to make decisions, you’ll use if, if...else, or switch. The first two are straightforward. switch is for when you have multiple cases to check and want your code to look like a retro telephone switchboard.

Try, Catch, Finally

When things break—and they will—wrap your code in try to run it, catch to handle errors, and finally for code that runs no matter what. Perfect for cleanup, logging, or making sarcastic comments after everything explodes.

Utilizing Error Objects

When JavaScript throws an error, it hands you an Error object. You can inspect it to figure out what went wrong, then decide whether to fix it, log it, or just pretend it never happened.

Expressions and Operators

Everything from + (plus) to === (strict equality) to ?? (these things) fall under expressions and operators. There are a lot of them: arithmetic, logical, assignment, comparison, bitwise… and a few that only show up to ruin your day if you forget how they work.

Functions

Functions are reusable chunks of code you can call whenever you want. They take optional parameters, return optional values, and sometimes cause non-optional headaches.

Arrow Functions

The arrow function is the hipster version of functions—shorter syntax, no own this binding, and looks cooler.

IIFE (Immediately Invoked Function Expression)

IIFEs are functions that run as soon as you define them. This is great for quick, one‑off code execution.

Recursion

Recursion is when a function calls itself until it hits a “base case” and stops. Use it for elegant problem solving… or infinite loops if you mess it up.

Closures

A closure is when a function remembers the variables from the place it was created, even after that place is gone. It’s like a function with a secret backpack of data.

Built‑in Functions

Stuff like parseInt(), setTimeout(), and Math.random()—plus methods on Array, String, and Date—are ready to use without writing them yourself.

DOM APIs

JavaScript can poke, prod, and completely rearrange your web page via the DOM. Change text, update styles, remove elements, add elements—it’s all fair game.

The `this` Keyword

this changes depending on how and where you use it. Sometimes it’s the object you’re in, sometimes it’s the global object, and sometimes it’s undefined—because JavaScript loves to keep you guessing.

Asynchronous JavaScript

Some tasks—like fetching data or using a camera—take time, so JavaScript handles them asynchronously. That means your code can keep running while it waits for results.

Callbacks, Callback Hell, and Async/Await

Callbacks are functions passed into other functions. Too many nested callbacks turn your code into “callback hell”—a pyramid of doom. Async/await fixes that by making asynchronous code look synchronous, which your future self will thank you for.

Fetch

fetch() lets you grab data from servers and APIs. It returns a promise, which you can await like the cool kids.

Modules

Split your code into separate files, export what you need, and import it where you need it. Modules keep things organized and your sanity intact.

Chrome DevTools & Debugging

Every browser has dev tools for inspecting HTML & CSS, running JS in the console, setting breakpoints, and checking performance. Chrome’s Lighthouse can even rate your website—though be prepared for a brutal honesty session.

Now it’s your turn: pick a project, start building, break things, fix them, and repeat until you accidentally become a JavaScript developer.

Forem: Fabian Frank Werner

Uh oh... Cloudflare just turned evil

Part 1: Anti-bot. Pro-web.

Part 2: Hello, Crawler!

Part 3: Friendly fire...

Part 4: Gatekeeper. Gateway. Tollbooth.

Elysia in 100 Seconds

Python vs Ruby - I built the same github analyzer with both

Code Hike in 100 Seconds

An Honest Review of Google Antigravity

JavaScript vs TypeScript - I built the same crypto tracker with both

Setup

Structure

Data

Trap

Refactoring

Performance

Verdict

CSS vs Tailwind CSS - I built the same home page with both

Chapter 1: The Setup

Chapter 2: The Reset

Chapter 3: The Colors

Chapter 4: The Layout

Chapter 5: The Problem

Chapter 6: The Specifics

Chapter 7: The Compiler

Chapter 8: The Paradox

Chapter 9: The Verdict

OpenAI's Browser is here… and 7 more things that shipped this week

10 Dead Programming Languages

[Boost]

How to ACTUALLY learn JavaScript... A roadmap for beginners

Inner Join vs Left Join vs Right Join vs Full Join

But first… What’s a Join?

Inner Join

Left Join

Right Join

Full Join

The Self Join

The Cross Join

The Natural Join

How to ACTUALLY learn JavaScript... A roadmap for beginners

What is JavaScript?

A Brief (and Weird) History of JavaScript

How to Run JavaScript

Scopes (a.k.a. Where Your Variables Live and Die)

Datatypes

Implicit Type Casting (a.k.a. “JavaScript Will Guess for You”)

Keyed Collections

JSON

Value Comparison Operators

Loops and Iterations

Conditional Statements

Try, Catch, Finally

Utilizing Error Objects

Expressions and Operators

Functions

Arrow Functions

IIFE (Immediately Invoked Function Expression)

Recursion

Closures

Built‑in Functions

DOM APIs

The this Keyword

Asynchronous JavaScript

Callbacks, Callback Hell, and Async/Await

Fetch

Modules

Chrome DevTools & Debugging

The `this` Keyword