Forem: Jimmy McBride

Think of Nodes like Lego bricks. Each one has a specific purpose, and when you start snapping them together, you can build literally anything — from a main menu to a full 3D world.

🧱 What Is a Node, Really?

A Node is the most basic building block in Godot.
It’s a single piece of functionality — like “draw a sprite,” “play a sound,” or “run this script.”

Every Node has:

A name — how you reference it in the tree.
A type — what kind of thing it is (like Sprite2D, Camera2D, Timer, etc.).
A parent and children — Nodes form hierarchies.
And optionally, a script attached for custom behavior.

You can think of it like this:

Player (Node2D)
├── Sprite2D
├── CollisionShape2D
└── Script (GDScript or C#)

Each part of the player — the art, the physics, the logic — is just another Node.

🌲 The Scene Tree

When you look at your project in Godot, everything is organized in a scene tree.
Every scene (yes, every .tscn file) is actually just a saved tree of Nodes.

For example, your main scene might look like this:

MainScene
├── Player
│   ├── Sprite2D
│   └── Camera2D
└── EnemySpawner
    ├── Timer
    └── Marker2D

Each node has a parent, and each parent can have children.
If you move or delete the parent, everything underneath it moves or deletes too — just like folders and files.

That’s why you’ll often hear people say:

“Once you understand the scene tree, you understand Godot.”

🧩 Different Types of Nodes

There are hundreds of node types in Godot, but here are a few of the main categories you’ll use constantly:

Node Type	Purpose
`Node2D` / `Node3D`	Anything that exists in 2D or 3D space (position, rotation, scale)
`Control`	UI elements like buttons, labels, panels
`AudioStreamPlayer`	Plays sounds or music
`Area2D` / `CollisionShape2D`	Detects overlaps and collisions
`Timer`	Runs code after a delay or on a loop
`Node`	The most basic type, purely for logic or grouping

Each Node type comes with built-in properties and functions.
For example, Node2D has position, rotation, and scale.
You can move it with a single line:

GDScript

extends Node2D

func _process(delta):
    position.x += 1

public partial class Mover : Node2D
{
    public override void _Process(double delta)
    {
        Position = new Vector2(Position.X + 1, Position.Y);
    }
}

🪜 Parents, Children, and Hierarchies

Nodes don’t live alone — they live in hierarchies.

If you move a parent node, all its children move with it.
If you delete a parent, its children go too.

That’s powerful because it lets you build self-contained systems.
Your Player node might have a Camera2D, Sprite2D, and CollisionShape2D as children — all following the player automatically.

You can also communicate easily:

GDScript

# From a parent to a child
$ChildNode.visible = false

# From a child to its parent
get_parent().do_something()

// From a parent to a child
GetNode<Node2D>("ChildNode").Visible = false;

// From a child to its parent
(GetParent() as ParentClass)?.DoSomething();

It’s a simple but elegant system.
You don’t need a big “GameObject” class or complex component setup — Nodes are the components.

🧱 Scenes: Reusable Node Trees

Here’s the best part: a Scene in Godot is just a saved tree of nodes.

You can make a Player scene, save it, and then drag it into your Level scene — and it becomes a single node with all its children tucked neatly inside.

LevelScene
├── Player (instanced scene)
├── Enemy (instanced scene)
├── Background
└── UI

That means you can design your Player once and reuse it in every level.
Godot’s scene system is modular by design — build small, combine big.

⚙️ Adding Behavior with Scripts

Nodes can do a lot on their own, but when you want custom logic, you attach a script.

GDScript

extends Node2D

@export var speed = 200

func _process(delta):
    position.x += speed * delta

using Godot;

public partial class Player : Node2D
{
    [Export] public float Speed { get; set; } = 200f;

    public override void _Process(double delta)
    {
        Position += new Vector2(Speed * (float)delta, 0);
    }
}

That’s it — you’ve just given your node behavior.
Scripts turn nodes from static data into dynamic, interactive parts of your game.
Every script “extends” the node it’s attached to — meaning it is that node.
extends Node2D means your script is a Node2D with extra powers.

⚡ Signals: How Nodes Talk to Each Other

Signals are Godot’s event system.
They let nodes communicate without directly depending on each other — which keeps your code clean.

GDScript

# Player.gd
signal died

func die():
    emit_signal("died")

# MainScene.gd
func _ready():
    $Player.connect("died", self, "_on_player_died")

func _on_player_died():
    print("Player died!")

// Player.cs
[Signal]
public delegate void DiedEventHandler();

public void Die()
{
    EmitSignal(SignalName.Died);
}

// MainScene.cs
public override void _Ready()
{
    var player = GetNode<Player>("Player");
    player.Died += OnPlayerDied;
}

private void OnPlayerDied()
{
    GD.Print("Player died!");
}

That’s it — your MainScene knows when the Player dies, but the Player doesn’t care who’s listening.
It just says “Hey, I died!” and anyone connected gets the message.

🕹️ Example: Building a Simple Player

Let’s put it all together.

Scene Tree

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

GDScript Version

extends CharacterBody2D

@export var speed = 200

func _physics_process(delta):
    var input = Vector2.ZERO
    input.x = Input.get_action_strength("ui_right") - Input.get_action_strength("ui_left")
    input.y = Input.get_action_strength("ui_down") - Input.get_action_strength("ui_up")
    velocity = input.normalized() * speed
    move_and_slide()

C# Version

using Godot;

public partial class Player : CharacterBody2D
{
    [Export] public float Speed { get; set; } = 200f;

    public override void _PhysicsProcess(double delta)
    {
        var input = Vector2.Zero;
        input.X = Input.GetActionStrength("ui_right") - Input.GetActionStrength("ui_left");
        input.Y = Input.GetActionStrength("ui_down") - Input.GetActionStrength("ui_up");

        Velocity = input.Normalized() * Speed;
        MoveAndSlide();
    }
}

You’ve got:

A node for position and physics
Children for visuals and collision
A script to control movement

That’s a playable character — no boilerplate, no setup pain, just nodes working together.

🧠 Wrapping Up

Once you understand Nodes, everything in Godot makes sense.
You stop thinking in terms of “objects” or “entities” and start thinking in trees — small, simple parts that combine into something powerful.

From GDScript to C#: A Practical Guide to Converting Your Godot Scripts

Jimmy McBride — Thu, 06 Nov 2025 14:53:37 +0000

So you’ve been hacking away in GDScript for a while, and now you’re thinking about switching to C#. Good choice.
Static types are king.

The Godot editor gives you a ton of quality-of-life features out of the box — but so do IDEs like Rider and Visual Studio. When you combine Godot’s workflow with a full-power IDE, you get code completion, refactoring tools, and static analysis that GDScript just can’t match yet.

C# is faster, safer, and (honestly) just feels right if you already love strong typing and compiler-enforced correctness. Let’s walk through exactly how to take your GDScript and translate it into clean, idiomatic C#.

🧩 Basic Syntax Differences

GDScript and C# share a lot conceptually — both are high-level and friendly — but their syntax philosophies couldn’t be more different.

GDScript	C#
`extends CharacterBody3D`	`public partial class Player : CharacterBody3D`
`func _ready():`	`public override void _Ready()`
`pass`	`// empty body`

Notes:

C# requires explicit return types (void, int, etc.).
Use braces {} instead of indentation.
Don’t forget the partial keyword — Godot uses it to inject engine bindings.

⚙️ Export and OnReady Variables

In GDScript, you’d write:

@export var speed := 10
@onready var sprite = $Sprite

In C#, that becomes:

[Export] public int Speed { get; set; } = 10;
private Sprite2D _sprite;

public override void _Ready()
{
    _sprite = GetNode<Sprite2D>("Sprite");
}

You can’t use @onready — you’ll grab your nodes in _Ready().
Think of [Export] as the C# equivalent of @export, just with attributes instead of decorators.

📡 Signals — The C# Way

Here’s a simple GDScript signal:

signal died

func die():
    emit_signal("died")

And here’s its C# twin:

[Signal] public delegate void DiedEventHandler();

public void Die()
{
    EmitSignal(SignalName.Died);
}

Connecting is where C# really shines.
Forget Connect() — use the event-style += syntax instead:

public override void _Ready()
{
    Died += OnDied;
}

private void OnDied()
{
    GD.Print("Player died!");
}

It’s cleaner, type-safe, and plays nicely with your IDE’s autocomplete.
If you’ve used C# events before, you’ll feel right at home.

🌳 Node Access and the Scene Tree

This one’s easy: $NodePath in GDScript becomes GetNode<T>() in C#.

@onready var enemy = $Enemy

private Node2D _enemy;

public override void _Ready()
{
    _enemy = GetNode<Node2D>("Enemy");
}

Want null safety? Use ? and as:

var enemy = GetNode("Enemy") as Node2D;
enemy?.QueueFree();

🌍 Autoloads and Global Classes

In GDScript, your autoload might look like this:

extends Node
var score = 0

In C#:

public partial class Global : Node
{
    public int Score { get; set; }
}

Then go to Project → Project Settings → AutoLoad, add Global.cs, and check “Enable”.
Now you can access it from anywhere:

var global = (Global)GetNode("/root/Global");
global.Score += 1;

🔁 Lifecycle Methods

GDScript	C#
`_ready()`	`_Ready()`
`_process(delta)`	`_Process(double delta)`
`_physics_process(delta)`	`_PhysicsProcess(double delta)`
`_input(event)`	`_Input(InputEvent @event)`

Each method name is PascalCase and usually takes a double delta instead of a float.

🎮 Input Handling

if Input.is_action_just_pressed("jump"):
    jump()

if (Input.IsActionJustPressed("jump"))
    Jump();

The method names are PascalCase (IsActionJustPressed) but otherwise identical.

🧱 Collections and Loops

Arrays and dictionaries work similarly, just more explicit in C#.

var enemies = []
for i in range(10):
    enemies.append(i)

var enemies = new Godot.Collections.Array<int>();
for (int i = 0; i < 10; i++)
    enemies.Add(i);

Or go pure C#:

var enemies = new List<int>();

⏳ Async / Await vs Yield

GDScript’s await is awesome, but in C# it maps differently:

await get_tree().create_timer(1.0).timeout
print("done!")

await ToSignal(GetTree().CreateTimer(1.0), SceneTreeTimer.SignalName.Timeout);
GD.Print("done!");

You can use normal async/await patterns anywhere now — no coroutines or yield() required.

🧠 Common Gotchas

Double vs float: Godot 4 uses double for most math types.
Recompile: Adding a new C# file? You need to rebuild the project.
Export fields: [Export] only works on public properties (not private fields).
Partial keyword: If you forget it, the script won’t load.
Case sensitivity: _Ready, not _ready.

⚖️ When to Use C# vs. GDScript

Use GDScript for fast prototyping, quick editor tools, or when you just want to stay inside Godot’s ecosystem.
Use C# for large projects, stronger architecture, and cleaner maintenance long-term.
You can mix both. Godot lets C# and GDScript talk to each other easily.

💬 Final Thoughts

Switching from GDScript to C# isn’t just about syntax — it’s about mindset.
C# gives you structure, safety, and serious IDE power without losing what makes Godot fun.

Self-Host Your Digital Empire: 4 Open-Source Essentials

Jimmy McBride — Mon, 28 Oct 2024 13:37:29 +0000

If you're like me and are tired of being treated like a data cow by big tech, dealing with vendor lock-in, overpaying for slow, complicated services, and working with companies that act more like a band of Sith lords than true Jedi knights, this blog is for you.

In this post, we'll go over the four essential tools that, in my opinion, create the strongest foundation to build and self-host your own digital empire. Forget the dark side—join the open-source revolution and go to sleep at night knowing you have control! No more waking up to a sky-high AWS bill because you forgot to shut down a test instance or left an S3 bucket unrestricted. Join me, and let's rest in victory together!

Coolify

Coolify lives up to its name—it’s just that cool! Imagine being able to self-host your own open-source alternative to platforms like Netlify, Vercel, or Railway. Now stop imagining, because it’s already a reality! Just SSH into a fresh VPS in the cloud—or even better, into your own home lab—paste a single command, and it installs everything you need! Coolify covers nearly all of your self-hosting needs, with Kubernetes support on the way. Here’s a list of some key features Coolify offers:

Effortless Deployment Options: Say goodbye to tedious setups—deploy full-stack apps with Docker, static sites, databases, and more with just a few clicks. Plus, Coolify supports the nixpacks.toml build file for your projects, adding even more flexibility and control.
Built-In Database Management: Coolify has your database needs covered with support for PostgreSQL, MySQL, MongoDB, and Redis. No extra installs—just click, deploy, and go.
Custom Domain Management: No more manual configurations—Coolify automates custom domains and SSL certificates, taking the hassle out of secure hosting.
Seamless CI/CD Pipelines: It’s basically DevOps on autopilot. Every time you push to Git, Coolify can rebuild and redeploy your project—hands-free and hassle-free.
Resource Monitoring and Alerts: Stay on top of your server resources with real-time monitoring and alert notifications. Know what’s happening as it happens.
Privacy-First and Self-Hosted: Own your data, your setup, and your infrastructure—no middleman, no vendor lock-in. Coolify puts you in complete control.

AppWrite

If you're ready to ditch Firebase but want a robust, open-source backend, AppWrite is a game-changer. AppWrite gives you a powerful, full-featured backend with authentication, databases, storage, and more—all in one place. What’s even cooler? You can launch AppWrite with a single click right from Coolify's app section! No more painful configurations or piecing together multiple services; AppWrite has the essentials you need to kickstart any project.

Here’s why AppWrite stands out:

Effortless Authentication: With built-in support for OAuth providers like Google, GitHub, and more, AppWrite handles user authentication without all the setup hassle.
Flexible Database Management: Whether you need NoSQL or SQL-style collections, AppWrite's databases offer powerful querying options, letting you store and retrieve data the way you want.
File Storage Simplified: Easily manage files and images in the cloud with AppWrite’s storage API. Upload, retrieve, and manage files all from your backend.
Real-Time Functionality: Real-time capabilities make AppWrite ideal for apps that need to update live, from chat apps to collaborative projects. No extra setups or workarounds—just instant data updates.
Self-Hosted, Privacy-First: Like Coolify, AppWrite is built with your privacy in mind. You’re in control, which means no more vendor lock-in or data-sharing concerns.
Multi-Platform SDKs: AppWrite offers SDKs for Web, iOS, Android, and Flutter, so you can use it no matter what platform you're developing for.
One-Click Deployment with Coolify: That’s right—Coolify makes deploying AppWrite easier than ever. Just click to install, and you’re ready to roll.

With AppWrite, you can take control of your app’s backend without compromising on features or flexibility. It's the perfect Firebase alternative, especially if you're looking to keep things open-source and in-house!

Plausible

I don’t know about you, but Google Analytics always felt like deciphering the Da Vinci Code. Trying to make sense of endless data streams just left me frustrated, and I felt like I was constantly missing the big picture. Enter Plausible, the open-source analytics tool that changed everything. Plausible is designed to keep things simple, clean, and focused on what actually matters, and when I switched, I felt so happy that I could cry.

With Plausible, tracking analytics is so easy that I’m still kicking myself for not making the move sooner. And, if you’re into getting hands-on, Plausible has an API that makes accessing and manipulating your analytics data an absolute joy. It's as easy as grabbing a bite-sized data summary or as powerful as using that data to build out custom dashboards or reports for your own needs. The flexibility here is chef’s kiss!

Here’s why Plausible is a no-brainer:

Privacy-First Approach: Plausible doesn’t track visitors across the internet or gather data on their lives. It’s privacy-first, which is a major win if you’re looking to keep your site respectful of user privacy.
Simple, Clear Metrics: Forget the data dump. Plausible gives you the essentials, like page views, referral sources, top pages, and bounce rates—all in a layout that makes sense. No unnecessary frills, just pure, actionable insights.
Real-Time Analytics: Get updates instantly. Plausible's real-time data means you can stay on top of trends, check your live metrics, and react to new traffic patterns without waiting around.
Easy API Access: Plausible’s API makes it effortless to pull analytics data and use it however you need. Whether you’re creating custom reports or embedding metrics into a dashboard, it’s fully programmable and at your fingertips.
One-Click Setup with Coolify: Just like AppWrite, Plausible has a one-click deployment in Coolify, so getting it running is practically automatic.

Plausible lets you take back control of your analytics without the clutter and without handing your data over to big tech. If you want clean, simple insights with an emphasis on privacy, this tool is a must-have in your self-hosted stack!

SvelteKit

Saving the best open-source tool for last: SvelteKit! In my (factually correct) opinion, SvelteKit is the ultimate meta framework. With the launch of Svelte 5 and its new runes feature, it's truly a game changer. Writing reactive logic for SSR, static, and client-side apps has never been simpler or faster. SvelteKit strips out all the unnecessary bulk, giving you a lean, blazing-fast framework that's a genuine pleasure to build with. If you’re aiming to make efficient, fast, and modern web apps, SvelteKit has you covered!

Conclusion

In a world dominated by big tech and proprietary tools, building and hosting your own digital empire has never been more accessible. By leveraging open-source tools like Coolify, AppWrite, Plausible, and SvelteKit, you're taking control over your data, finances, and the entire process—without the downsides of vendor lock-in or hidden costs. It’s time to harness these powerful tools, craft something truly your own, and create a digital presence with freedom, efficiency, and transparency at its core.

Ready to join a community of like-minded creators and tech enthusiasts? Join us over in The Developer’s Lounge on Discord! We’re a group that’s all about open-source, coding, and building cool things. We’d love to see you there!

I Survived a Massive DDoS Attack and Made My Server Bulletproof

Jimmy McBride — Tue, 22 Oct 2024 21:34:02 +0000

So, maybe you can relate... I can be a bit of a noob sometimes! I decided to migrate my website to 100% open-source and self-hosted tools, and I forgot one major step. I didn’t fully understand that step, so now I want to help you understand how not to get every hacker and their dog's bot spamming the open SSH port you forgot to hide behind a firewall. 😬

Firewalls! 🔥🔥🔥

Let’s talk about firewalls! There are 2 types of firewalls we need to know about: cloud firewalls and traditional firewalls.

Traditional Firewall: A traditional firewall is a security system installed directly on your server’s hardware. It sets up rules for who is allowed to connect to what port on your server. It’s a very useful tool for making sure only the right people have access to a given port. However...
Cloud Firewall: A cloud firewall is a network-level firewall. What’s significant about this is that it can stop traffic before it even reaches your server!

So, while I did set up key-based authentication on my server, making it impossible for anyone to brute force their way in, the number of denied requests to that server consumed a lot of CPU and IO rate—enough to take my site down! Trying to figure out what was happening was almost impossible because the server was so slow! Even setting up the traditional firewall didn’t stop hackers from bombarding my SSH port! However, once I set up a cloud firewall through my provider (DigitalOcean, not a sponsor but open to the idea 😉😉), the bots couldn’t even reach my server’s SSH port at all. No need for obscurity! I can keep my SSH on port 22, and you can’t even touch it! 🚀

However, I can’t block website traffic to my blog, so I can still be DDoSed through those ports, but hey, a win’s a win!

Join The Community

If you like what you’ve read, love to code, and are a fan of Linux, open source, and building your own projects, you’d probably have a great time in my Discord community, The Developers Lounge! We’re a rapidly growing community with lots of great people with a diverse set of skills among us. I’m super active in here, and we have a ton of cool people just waiting to chat. So what are you waiting for? Hop on in!

Be Real: How to Use AI Writing Tools and Stay Authentic

Jimmy McBride — Thu, 10 Oct 2024 19:42:18 +0000

Once you've read one ChatGPT article, it feels like you've read them all. The phrase "Let's dive in" is forever tainted, and the cheesy metaphors are a dead giveaway that you're reading AI-generated content. In this blog, I'd like to talk about my experience using AI writing tools in my own blog. I'll go over different methods I've tried, their pros and cons, and how I'm using AI to write now. My aim is to share my experience in a way that helps you keep your authentic voice so that you don't come across as just another AI blog writer.

If you’re like me, you've probably experimented with AI at some point and realized that while it can help you pump out blogs quickly, it also removes that human element from your content that it used to have. So why would anyone want to use AI-generated content in their blog? Firstly, it saves time and effort! But don't be fooled! Saving too much time and effort will tank not only the quality of your work but your reputation too! Now, I get it. When ChatGPT first came out, I did what most other people did: "ChatGPT, write me a blog about xyz." Then maybe you do a little proofreading, ask it to make some changes, and post it to your blog. Suddenly, producing new content is so easy that you're able to keep up with publishing a blog a day! Woohoo, right? Not really.

The obvious downside to this approach is what I mentioned in the first sentence of this blog. The cheesy metaphors and the overuse of phrases like "Let's dive in." If you're not a subject matter expert, or lazy, it's really easy to put out either inaccurate or misleading information. Many times, when reviewing AI-generated content, I’ve found much more efficient ways to achieve the same results when I’m trying to produce more technical guides. Additionally, people are tired of reading content generated by AI. They want something from a real person who’s an actual subject matter expert! They want something authentic. So what’s the solution? That’s right—it’s time to ditch AI-generated content!

AI-Generated Content vs. Human-Generated Content

Have you ever read a blog and thought, "This was for sure wrtten by AI"? People don’t want to read an article they feel like was created by an empethic robot. They can easily prompt an LLM to do that themselves. They’re looking for your unique human touch and expertise. When you’re discussing a subject you have years of experience in, there’s so much nuance you can add to your content that AI could never capture. That’s what people crave! They want to hear about your personal experiences. What are some of the real joys and pitfalls you’ve encountered along your journey? Have you run into an issue that’s caused you trouble more than once? It’s anecdotes like these that provide real value and build your authenticity. The brand is you. Sure, AI can pull the facts together, but it’s not living your life or walking in your shoes. It can't bring in that experience or those weird anecdotes that makes your work stand out. You just can’t fake those kinds of things. They have to come from you.

That’s the difference between AI-generated content and human-generated content. But just because it’s human-generated content doesn’t mean that AI can’t play a role in making your life easier. After realizing this, my next evolution was to write human-generated content that was AI-edited. This approach was better but still not perfect. So how can we use AI as a tool to help with our writing without letting it take over and drown out our voice?

Using AI To Edit Your Human-Generated Content

The first way I improved my terrible AI blog-writing workflow was to train a ChatGPT conversation on ALL of my blogs that I wrote before ChatGPT ever came out so that it could understand my “voice” as an author better. Then I would write the rough draft, let whatever I was thinking come out, give that to ChatGPT, and have it turn my loose rough draft into a bonafide blog. This was much better than before. Now I was able to capture my own experiences, nuance, and opinions and have ChatGPT use my “style” to turn it into a final draft blog. This definitely takes more effort, but being able to turn a 30-45 minute-long freewriting session into a final draft blog ready to publish is still a huge win and time saver! Plus, there’s this air of consistency in my blogs now that wasn’t there before.

However, it still wasn’t perfect. Getting comments like, “This feels very LLM generated” on my blog, Why Writing Your Own Tools is More Important Than You Think, really hurt. I took time out of my day to write my honest opinions about writing your own tools and the benefits and even drawbacks that come with it. Regardless of being edited by ChatGPT, that blog still reflects how I feel about the topic. However, it seems like my approach had put a stain on my reputation and damaged my authority as an author. That hurt. But sometimes, experiencing that kind of hurt is exactly what you need! So yes, it was something I wrote, edited by AI trained to sound like me, but it was obvious that the end product still didn't sound like me. The fact was, I was still trying to take a shortcut to the top, and people noticed. Having your real experience and nuance reduced to “This feels very LLM generated” is not a good feeling. So what’s a blogger, author, or content creator to do?

It’s time to stop being lazy!

Do I Still Use AI?

Yes, I do! However, I’m no longer letting AI write or rewrite my content anymore. Not only am I doing my followers and fans a disservice by giving my voice as an author over to AI, but I’m also doing myself a disservice by not continuing to hone my craft and writing style. Writing is a huge passion of mine. If I give that passion away to AI to do for me, what’s to stop me from giving away my other passions to AI? Should I let AI play and write music for me? Should I let AI skateboard for me? No! What makes passions so beautiful is that the joy doesn’t come from the end product, it comes from the process! If I let AI write my blogs for me, what joy do I get out of writing blogs? And for what? I want to build something real and authentic that means a lot, not just to me, but to other people as well. I want to find the joy in this blog and my writing as I go along. I’m not in this game for cheap tricks, and I’m not doing this so I can build some kind of cash cow where one day I’ll sit on the beach and sip on margaritas every day. I want to build something meaningful that lasts, and I’m in this for the long haul.

Using AI Moving Forward

So what’s my plan for using AI in my content generation moving forward? First of all, AI is great at grammar and spelling, which I’m very bad at. If programmers were good at spelling, we wouldn’t have invented spell check! So I plan to use AI to grammar-check my work. Additionally, there are three other key areas where I plan to use AI when it comes to content creation:

Feedback: Bugging friends to pre-read my blogs and give me good feedback isn’t feasible, and I can’t afford to pay people to do that for me. So having something I can ask, “Is this good?” or “What are some ideas for improving xyz?” is very nice. Then I can take that feedback and apply my own voice when implementing it.
Research: AI and LLMs are great research tools! I can have them do Google searches for me and summarize articles and videos I find through my own searches, helping me get the most meaningful data I need to create whatever blog I’m working on.
Blog banner creation: Let’s face it, MidJourney is cool. I love using it, and I plan to continue using it to create banners for my blogs moving forward.

Now, will I be able to produce a blog a day anymore? Not really. However, while the quantity of my blogs will go down, the quality and authenticity of my blogs will rise! I’m really looking forward to creating higher-quality content for you all than ever before. No more shortcuts, no more cheap tricks. Just me. :)

So what about you? How have AI writing tools shaped your writing? Share your thoughts in the comments below!

Join The Community

The Ultimate Dev.to Hacks To Skyrocket Your Blog's SEO & Traffic

Jimmy McBride — Fri, 04 Oct 2024 19:47:16 +0000

SEO can be hard. Getting people to click and notice your original content can be soul-crushing in the beginning. For us techies, that's what makes a platform like Dev so great! It's a community of like-minded people there to read and support you along your journey. I started my journey blogging on Dev as a way to solidify what I was learning at a coding bootcamp. I was absolutely blown away by the amount of engagement I started to get. People were following me like crazy. I even remember the first time I won "Top 7 Most Popular Blog Of The Week"! I felt like I was on fire!

I remember thinking to myself that my dreams of creating valuable content that helps others out weren't as far off as I feared. So I started my own blog and began posting my Dev content there, but there was still so much I didn't know!

My aim with this blog is to help you understand how the system works, and leverage the tools in place to drive traffic to your official blog and ensure your actual blog shows up in search engines rather than your Dev post. Duplicate content can be penalized in SEO if you don't do it correctly, so I'm here to show you how to do things the right way and work with the Dev platform to get great SEO rankings, driving traffic to your official website. It almost feels like you're hacking Dev's domain authority and popularity for your own website, making competing for that front page and top spot so much easier when you're starting out.

I truly believe Dev can serve as a great tool when growing your audience in the tech space, so here's how I use Dev's platform to get traffic and SEO boosts!

Canonical Links: Why You Need Them

So, first up canonical links. If you're publishing the same content to your blog and platforms like Dev.to or Medium, then you'll need to let search engines know where the official version lives. That's what canonical links are for. They allow Google - and others - to understand which version of your blog is the "original" or "canonical" source.

That means if you do not have a canonical link, search engines may index the duplicate content on Dev.to or Medium, and they may think it is the original. You would be driving visitors away from your personal site to Dev.to, even though it's your blog content!

So here's how you'd add a canonical link to your Dev.to post, for instance:

Then on your offical blog, you can add a link in your header pointing to your site as the canonical link as well.

<link rel="canonical" href="https://your-website.com/your-post-slug" />

This tells Google, "Hey, this post lives officially on my blog, not on this platform." In this way, the search engines will rank higher your personal blog when showing the results.

Why Canonical Links Alone Aren't Enough

Now, here is where things get interesting. Canonical links alone don't always ensure that your blog shows up in search results first--especially if Dev.to or Medium has been indexed more quickly because of the size and traffic of their platforms.

For example, if you publish to Dev.to and to your own blog simultaneously, search engines might index the Dev.to one first because large platforms like Dev.to are crawled more often. In that case, even when the canonical link is present, your blog could be outranked by your own Dev.to post!

This is where sitemaps and Google Search Console save your bacon.

Sitemaps: Your Fast Pass for Indexing

That's what sitemaps are for: it helps search engines understand the architecture of your website and index your content quicker. Think of it this way: you’re giving Google a clear roadmap to your content, pointing out exactly where each important piece is located—like marking all the key spots on a map—so it knows exactly where to return and crawl your site efficiently.

In SvelteKit, you can dynamically generate a sitemap to help search engines like Google keep up with your latest blog posts as they are published. Here’s the sitemap.xml implementation I use for my SvelteKit blog:

import { url } from "$lib/config"
import { SitemapStream, streamToPromise } from "sitemap"
import { Readable } from "stream"
import type { RequestEvent } from "@sveltejs/kit"

export const GET = async ({ fetch }: RequestEvent) => {
    const response = await fetch("/api/posts")
    const posts: Post[] = await response.json()

    const links = posts.map((post: Post) => ({
        url: `/blog/${post.slug}`,
        changefreq: "weekly",
        priority: 0.8,
    }))

    const stream = new SitemapStream({ hostname: url })

    return new Response(
        await streamToPromise(Readable.from(links).pipe(stream)).then((data) => data.toString()),
        {
            headers: {
                "Content-Type": "application/xml",
            },
        }
    )
}

export const prerender = true

This allows Google to be notified of new blog posts automatically as they are published, which can help boost your blog's SEO rankings. For those using other frameworks, you can adapt this approach to fit your needs. For Node.js users, the sitemap npm package is super handy for generating and managing your sitemaps.

Once your sitemap is ready, this needs to be submitted to Google Search Console so that Google knows exactly where to look for your content.

Google Search Console: Your Control Center for Indexing

And so brings us to Google Search Console. If you're serious about SEO, well, this tool is not optional.

Here's what you do:

Submit Your Sitemap: Navigate to Google Search Console, click the Sitemaps section, and submit your sitemap URL - for example, https://your-site.com/sitemap.xml.

Request Indexing: Once you've submitted your sitemap, you can then go into Google Search Console and request indexing of your posts immediately without having to wait for Google to crawl your site. Within URL Inspection Tool, you put your blog URL and hit Request Indexing. That's you telling Google, "Hey, I've got new content—check it out!"

This will ensure that your personal blog gets indexed sooner and appears higher than your posts on Dev.to and Medium.

The Full SEO Picture

So, here's the recap: Canonical links help Google understand which blog is the "official" version, whereas sitemaps and Google Search Console ensure your site gets indexed and appears in search results first. If you don't do all three, then you will probably find your Dev.to or Medium posts outrank your blog.

It's a little extra effort, but it's worth it when you see that the traffic is going directly to your site-and not someone else's.

Wrapping Up: SEO Done Right

By now, if you have worked hard in creating and growing your tech blog, these tips will put you in full command of your SEO strategy. Keep in mind, though, that everything is about securing your site with much-deserved visibility in the search engines.

I'll be covering backlink strategies in an upcoming article, so if you're interested in learning more about boosting your blog's visibility, stay tuned!

Got thoughts, questions, or tips of your own? Join us over in The Developers Lounge and let's chat about SEO, blogging, and everything tech!

Happy blogging!

Build The Perfect Tech Blog With SvelteKit

Jimmy McBride — Thu, 03 Oct 2024 14:10:45 +0000

In this tutorial, we’ll build a fully-functional, SEO-friendly blog using SvelteKit, Tailwind CSS, and Shiki for beautiful syntax highlighting. We’ll also use mdsvex for markdown support, remark-unwrap-images and remark-toc for handling images and generating table of contents, and rehype-slug for clean URL slugs.

By the end of this tutorial, you’ll have a responsive blog with markdown support, code highlighting, and metadata display. Let’s dive in step-by-step!

Step 1: Setting Up SvelteKit and Tailwind CSS

1.1 Install SvelteKit

To get started, we first need to set up a SvelteKit project. Run the following commands to initialize a new project:

npm create svelte@latest my-blog
cd my-blog
npm install

1.2 Install Tailwind CSS

Next, let’s integrate Tailwind CSS for styling. Tailwind is perfect for building responsive and aesthetically pleasing layouts for blogs.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init tailwind.config.cjs -p

Update your tailwind.config.cjs file to point to the content paths for Tailwind to scan for utility classes:

module.exports = {
    content: ["./src/**/*.{html,js,svelte,ts}"],
    theme: {
        extend: {},
    },
    plugins: [require("@tailwindcss/typography")], // Add typography support for better blog post styling
}

In your src/app.css, import Tailwind’s base styles:

@tailwind base;
@tailwind components;
@tailwind utilities;

Then let's update our src/routes/+page.svelte:

<h1>Welcome to My SvelteKit Blog!</h1>
<a class="text-blue-500" href="/blog">View my blogs!</a>

Finally, include this CSS file in your src/routes/+layout.svelte:

<script lang="ts">
    import "../app.css"
</script>

<main class="container mx-auto h-full">
    <slot />
</main>

Now, you’ve got Tailwind ready for responsive styling!

Step 2: Setting Up Markdown Parsing with mdsvex and Shiki

We’ll use mdsvex to parse markdown files and Shiki for beautiful syntax highlighting.

2.1 Install Required Dependencies

Install all necessary packages for markdown parsing and syntax highlighting:

npm install mdsvex shiki remark-unwrap-images remark-toc rehype-slug

2.2 Configure mdsvex and SvelteKit

Here’s the full svelte.config.js setup to enable mdsvex, Shiki, and plugins like remark-unwrap-images and remark-toc.

import adapter from "@sveltejs/adapter-auto"
import { vitePreprocess } from "@sveltejs/vite-plugin-svelte"
import { mdsvex, escapeSvelte } from "mdsvex"
import { bundledLanguages, createHighlighter } from "shiki"
import remarkUnwrapImages from "remark-unwrap-images"
import remarkToc from "remark-toc"
import rehypeSlug from "rehype-slug"

/** @type {import('mdsvex').MdsvexOptions} */
const mdsvexOptions = {
    extensions: [".md"],
    highlight: {
        highlighter: async (code, lang = "text") => {
            const highlighter = await createHighlighter({
                themes: ["one-dark-pro"],
                // this loads ALL languages. Will get better preformance by only calling what you need. Example: ["css", "javascript"]
                langs: Object.keys(bundledLanguages),
            })
            const html = escapeSvelte(highlighter.codeToHtml(code, { lang, theme: "one-dark-pro" }))
            return `{@html \`${html}\` }`
        },
    },
    remarkPlugins: [remarkUnwrapImages, [remarkToc, { tight: true }]],
    rehypePlugins: [rehypeSlug],
}

export default {
    extensions: [".svelte", ".md"],
    preprocess: [vitePreprocess(), mdsvex(mdsvexOptions)],
    kit: {
        adapter: adapter(),
    },
}

This setup enables markdown (.md) support and syntax highlighting with the One Dark Pro theme from Shiki.

Step 3: Creating Blog Posts in Markdown

Each blog post is written as a markdown file in the src/posts directory. Here's how a typical post might look:

Example Post: `src/posts/first-post.md`

---
title: "First Post"
description: "This is my first post!"
date: "2024-09-24"
image: /first-post-banner.webp
categories:
  - blog
  - tutorial
published: true
---

This is my first post!

## Let's get started

Lorem ipsum dolor sit amet...

This metadata in the frontmatter helps populate information like the title, description, date, and categories for each post. Important, to make sure images are working, please add an image in your /static folder named first-post-banner.webp so you can verify it works and nothing breaks.

Step 4: Fetching and Displaying Blog Posts

We’ll now create an API route to fetch blog posts and display them in a list. But before we move on, let's add a type for our Post to the app.d.ts for anyone following along in typescript:

// ...
interface Post {
    title: string
    slug: string
    description: string
    image?: string
    date: string
    categories: string[]
    published: boolean
}

4.1 Fetching Blog Posts

Create a server route src/routes/api/posts/+server.ts to load the markdown files:

import { json } from "@sveltejs/kit"

async function getPosts() {
    let posts: Post[] = []

    const paths = import.meta.glob("/src/posts/*.md", { eager: true })

    for (const path in paths) {
        const file = paths[path]
        const slug = path.split("/").at(-1)?.replace(".md", "")

        if (file && typeof file === "object" && "metadata" in file && slug) {
            const metadata = file.metadata as Omit<Post, "slug">
            const post = { ...metadata, slug } satisfies Post
            if (post.published) {
                posts.push(post)
            }
        }
    }

    posts = posts.sort(
        (first, second) => new Date(second.date).getTime() - new Date(first.date).getTime()
    )

    return posts
}

export async function GET() {
    const posts = await getPosts()
    return json(posts)
}

export const prerender = true

This function grabs all markdown files from the src/posts directory, extracts metadata, and returns an array of posts.

Why We're Using `export const prerender = true`

So you might be wondering, "What's up with the export const prerender = true in the blog post API route?" Well, here’s the deal—prerendering is one of the key benefits of using SvelteKit. By setting prerender = true, we're telling SvelteKit to generate the HTML for this page at build time rather than run time.

This has several major benefits for our blog:

Improved Performance: Since the HTML is generated ahead of time, when users hit our blog, they’re getting static files served right away instead of waiting for the server to dynamically build the page. This results in faster load times and a smoother user experience.
Better SEO: Prerendering also makes the blog more search engine friendly. Search engines like Google can easily crawl static pages, ensuring that all the important metadata (like blog titles, descriptions, etc.) is captured and ranked.
Reduced Server Load: Because the pages are prebuilt, there's no need to hit the server each time someone visits a blog post. This reduces the load on your server, saving you bandwidth and making your site more scalable—especially useful if your blog goes viral. 🙌

In short, prerendering helps make your blog faster, more efficient, and more SEO-friendly—exactly what you want when you're building a modern blog platform.

So, if you're curious about how to squeeze the most out of your blog, prerendering is one way to do it!

4.2 Displaying Posts in a Blog Page

Next, let’s build a page that lists all the blog posts. Create src/routes/blog/+page.server.ts to load posts:

import type { ServerLoadEvent } from "@sveltejs/kit"

export async function load({ fetch }: ServerLoadEvent) {
    const response = await fetch("/api/posts")
    const posts: Post[] = await response.json()
    return { posts }
}

4.3 Building the Blog Page Layout

We’ll display each blog post using a custom BlogCard component. Let's create src/lib/components/BlogCard.svelte:

<script lang="ts">
    import { formatDate } from "$lib/utils.js"
    import { title, description, url } from "$lib/config"

    export let post
</script>

<svelte:head>
    <title>{title}</title>

    <meta name="description" content={description} />

    <meta property="og:type" content="article" />
    <meta property="og:url" content={`${url}/blog`} />
    <meta property="og:title" content={title} />
    <meta property="og:description" content={description} />
    <meta property="og:site_name" content={title} />
    <meta property="og:image" content="/blog-banner.webp" />

    <meta name="twitter:site" content="@McBride1105" />
    <meta name="twitter:creator" content="@McBride1105" />
    <meta name="twitter:title" content={title} />
    <meta name="twitter:description" content={description} />
    <meta name="twitter:card" content="summary_large_image" />
    <meta name="twitter:image:src" content="/blog-banner.webp" />
    <meta name="twitter:widgets:new-embed-design" content="on" />

    <meta name="theme-color" content="#ffffff" media="(prefers-color-scheme: light)" />
    <meta name="theme-color" content="#000000" media="(prefers-color-scheme: dark)" />
</svelte:head>

{#key post.slug}
    <a class="card card-hover overflow-hidden w-full max-w-4xl mt-4 mx-4" href={`/blog/${post.slug}`}>
        <header class="mb-4">
            {#if post.image}
                <img src={post.image} alt="blog banner" />
            {/if}
        </header>

        <div class="p-4 space-y-4">
            <h3 class="h3" data-toc-ignore>{post.title}</h3>
            <article>
                <p>
                    {post.description}
                </p>
            </article>
        </div>
        <hr class="opacity-50" />
        <footer class="p-4 flex justify-start items-center space-x-4">
            <div class="flex-auto flex justify-between items-center">
                <h6 class="font-bold" data-toc-ignore>By Jimmy McBride</h6>
                <small>On {formatDate(post.date)}</small>
            </div>
        </footer>
    </a>
{/key}

4.4 Adding Format Date Util And Metadata Config

For our formatDate util we'll add src/lib/utils.ts:

type DateStyle = Intl.DateTimeFormatOptions["dateStyle"]

export function formatDate(date: string, dateStyle: DateStyle = "medium", locales = "en") {
    // Safari is mad about dashes in the date
    const dateToFormat = new Date(date.replaceAll("-", "/"))
    const dateFormatter = new Intl.DateTimeFormat(locales, { dateStyle })
    return dateFormatter.format(dateToFormat)
}

Finally, lets add our config file for some basic metadata information src/lib/config.ts:

import { dev } from "$app/environment"
export const title = "Your Website's Title"
export const description = "A description of your website."
export const url = dev ? "http://localhost:5173" : "https://yourproductionwebsite.com"

4.5 Using The BlogCard

Now we can use that component for our blog page src/routes/blog/+page.svelte:

<script lang="ts">
    import BlogCard from "$lib/components/BlogCard.svelte"
    export let data
</script>

<section class="mb-16">
    <ul class="flex flex-col items-center">
        {#each data.posts as post}
            <BlogCard {post} />
        {/each}
    </ul>
</section>

Now we should be about to a list of all our blogs!

Step 5: Displaying Individual Blog Posts

5.1 Fetching a Single Post by Slug

We need to create a [slug] route to display individual blog posts. Create the file src/routes/blog/[slug]/+page.ts:

import { error } from "@sveltejs/kit"
import type { ServerLoadEvent } from "@sveltejs/kit"

export const load = async ({ params }: ServerLoadEvent) => {
    try {
        const post = await import(`../../../posts/${params.slug}.md`)

        return {
            content: post.default,
            meta: post.metadata,
        }
    } catch (e) {
        throw error(404, `Could not find ${params.slug}`)
    }
}

5.2 Rendering the Blog Post

Finally, here’s how we render the full post content in +page.svelte:

<script lang="ts">
    import { formatDate } from "$lib/utils"
    import { url, title } from "$lib/config"

    export let data
</script>

<!-- SEO -->
<svelte:head>
    <title>{data.meta.title}</title>

    <link rel="canonical" href={`${url}${data.url}`} />
    <meta name="description" content={data.meta.description} />

    <meta property="og:type" content="article" />
    <meta property="og:url" content={`${url}${data.url}`} />
    <meta property="og:title" content={data.meta.title} />
    <meta property="og:description" content={data.meta.description} />
    <meta property="og:site_name" content={title} />
    <meta property="og:image" content={data.meta.image} />

    <meta name="twitter:site" content="@YouTwitterHandle" />
    <meta name="twitter:creator" content="@YouTwitterHandle" />
    <meta name="twitter:title" content={data.meta.title} />
    <meta name="twitter:description" content={data.meta.description} />
    <meta name="twitter:card" content="summary_large_image" />
    <meta name="twitter:image:src" content={data.meta.image} />
    <meta name="twitter:widgets:new-embed-design" content="on" />

    <meta name="theme-color" content="#ffffff" media="(prefers-color-scheme: light)" />
    <meta name="theme-color" content="#000000" media="(prefers-color-scheme: dark)" />
</svelte:head>

<article class="prose mb-16 mx-auto">
    <!-- Title -->
    <hgroup class="flex flex-col items-center">
        <h1 class="">{data.meta.title}</h1>
        <img src={data.meta.image} alt="blog banner" class="rounded-md" />
        <p class="text-end text-sm">
            Published at {formatDate(data.meta.date)}
        </p>
    </hgroup>

    <!-- Tags -->
    <div class="flex flex-wrap gap-4 mb-6">
        {#each data.meta.categories as category}
            <a href={`/blog/categories/${category}`} class="chip variant-filled-secondary no-underline"
                >&num;{category}</a
            >
        {/each}
    </div>

    <!-- Post -->
    <svelte:component this={data.content} />
</article>

Conclusion

And there you have it! A fully functional, SEO-optimized blog built with SvelteKit, Tailwind CSS, mdsvex, and Shiki. You now have the tools to write markdown-based posts with automatic syntax highlighting, responsive designs, and metadata for improved search engine performance. Whether you're sharing tutorials, documenting projects, or blogging about your passion, this setup has you covered for a modern web experience.

If you're as excited about creating awesome content as I am and want to hang out with other like-minded developers, feel free to join us over in The Developers Lounge. We’ve got a great community of coders who love to share, tinker, and help each other out. Hope to see you there! Discord Link.

Svelte the Difference: Solving Web Challenges with Ease

Jimmy McBride — Fri, 27 Sep 2024 13:36:02 +0000

Welcome back to our SvelteKit series! In Part 1, we covered what SvelteKit is and how it solves rendering challenges like SSR, SSG, and CSR. This time, we're diving deeper into SvelteKit's core features and the other problems it solves. Whether you’re building a simple static site, an interactive app, or something in between, SvelteKit has tools to handle the complexities for you.

If you’re new to frameworks but have experience with HTML, CSS, and JavaScript, this blog will explain how SvelteKit simplifies routing, layouts, data fetching, and more. By the end, you’ll have a strong grasp of what makes SvelteKit unique and how it makes modern web development smoother.

File-Based Routing

One of SvelteKit’s defining features is its file-based routing. Forget manually configuring routes—SvelteKit automatically generates them based on your file structure. Every file you add to the src/routes folder corresponds directly to a URL.

For example:

src/routes/about.svelte = /about
src/routes/blog/[slug].svelte = /blog/{dynamic-slug}

This means no configuration files to manage, no route declarations—just create files, and you’re good to go.

Dynamic Routes

Dynamic routing in SvelteKit allows you to handle routes that contain variables. For instance, if you’re building a blog where each post is accessed via a unique slug, you can create a dynamic route like this:

src/routes/blog/[slug].svelte

The square brackets tell SvelteKit that slug is a dynamic part of the route. This route will now match URLs like /blog/first-post and /blog/second-post, and the slug value will be available in your Svelte component.

<script context="module">
  export async function load({ params }) {
    const slug = params.slug;
    // Fetch post based on slug
  }
</script>

Layouts in SvelteKit

SvelteKit allows you to build layouts that wrap around all your pages, making it easy to manage headers, footers, and any content you want to be consistent across pages.

To set up a layout, create a __layout.svelte file in the src/routes directory. This layout file will automatically wrap all your routes, ensuring consistent styling and structure.

<!-- src/routes/__layout.svelte -->
<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

<main>
  <slot /> <!-- Route-specific content will be injected here -->
</main>

<footer>© 2024 My Website</footer>

You can also have nested layouts. For example, if you want a different layout for admin pages, just create a __layout.svelte inside the /admin directory. SvelteKit makes nesting and reusing layouts effortless, which is especially useful for apps with distinct sections like dashboards or blog post pages.

Rendering Strategies: SSR, SSG, CSR

In the world of modern web development, knowing when to use different rendering strategies is essential. SvelteKit simplifies this by giving you three main strategies to choose from, each with its own benefits.

1. Client-Side Rendering (CSR)

CSR means rendering happens in the browser. The initial load is often slower, but once the JavaScript has been loaded, interactions are fast.

When to use it: Single-page applications (SPAs) or apps with heavy user interaction that don’t require SEO.
Example: Dashboards, chat applications, or games where the content isn’t SEO-sensitive.

2. Server-Side Rendering (SSR)

With SSR, your HTML is pre-rendered on the server, then sent to the client. This means users see the page content almost immediately, which is great for SEO.

When to use it: When SEO is important or the app’s content is highly dynamic and needs to reflect changes instantly.
Example: E-commerce sites, blogs, and news sites where page load times and search engine rankings matter.

3. Static Site Generation (SSG)

SSG pre-renders your content into static HTML during the build process. These static pages are served quickly and don’t require server-side computation, making them ideal for performance.

When to use it: Sites that don’t require frequent updates or that can be updated in batches, like portfolios, blogs, or documentation.
Example: Marketing sites or documentation pages that are rarely updated.

Configuring Rendering in SvelteKit

SvelteKit makes it easy to switch between these strategies based on the needs of each route. To enable SSR or SSG, you can use the following in +page.js files:

export const ssr = true; // Enable server-side rendering

For static site generation:

export const prerender = true; // Pre-render the page during build

This flexibility lets you optimize each page in your application for speed, interactivity, and SEO as needed.

Conclusion

SvelteKit simplifies a wide range of development challenges—from routing and layouts to data fetching and SEO optimization. Whether you’re building a static blog, a dynamic web app, or something in between, SvelteKit has the tools to make the process easier and more efficient.

If you're as excited as I am about SvelteKit or want to ask questions, join us over in The Developers Lounge! We’ve got a welcoming community of developers who love to code, share knowledge, and help each other out. Join here.

SvelteKit Basics: A Crash Course

Jimmy McBride — Fri, 27 Sep 2024 03:02:20 +0000

Welcome to the second part of the SvelteKit series! If you're already comfortable with HTML, CSS, and JavaScript, but new to Svelte, you're in the right place. This post will give you a solid understanding of Svelte's fundamentals, setting the stage for you to dive into more advanced SvelteKit features later on.

What is Svelte?

Svelte is a front-end framework that helps you build reactive web applications with less boilerplate code than other frameworks like React or Vue. It’s unique because it compiles your code at build time, which means that the resulting application runs faster because there's no virtual DOM. Instead, Svelte updates the DOM directly.

Svelte is component-based, which means you build your app by composing reusable blocks of code (components) that each manage their own HTML, CSS, and JavaScript. This leads to clean, modular code that’s easy to manage as your app grows.

How is Svelte Different?

No Virtual DOM: Unlike React and Vue, Svelte doesn’t use a virtual DOM. It compiles your app into highly optimized vanilla JavaScript at build time.
Write Less Code: Svelte eliminates the need for concepts like useState (React) or data (Vue). Variables in Svelte are automatically reactive, which means they update the DOM whenever they change.

Getting Started with Svelte

Before diving into SvelteKit, let’s quickly cover Svelte’s core features.

1. Components

Svelte apps are built around components. Each Svelte component is just an .svelte file, which can contain three things:

HTML: The structure of your component.
CSS: Scoped styles that only affect the component.
JavaScript: Logic to control the component's behavior.

Here’s what a simple component looks like:

<script>
  let name = 'world';
</script>

<h1>Hello {name}!</h1>

<style>
  h1 {
    color: purple;
  }
</style>

In the example above:

<script> defines the JavaScript logic. The name variable is automatically reactive, meaning the DOM will update if the value of name changes.
<h1> is the HTML that will be rendered.
<style> is scoped CSS that only applies to this component.

2. Reactivity in Svelte

In Svelte, reactivity is automatic. Instead of calling setState or similar methods to update the UI, you simply assign new values to variables, and Svelte takes care of updating the DOM.

<script>
  let count = 0;

  function increment() {
    count += 1;
  }
</script>

<button on:click={increment}>
  Click me! {count}
</button>

The {} syntax is used for binding variables into HTML. Every time you click the button, the value of count is updated, and the DOM reflects the new value automatically.

3. Props in Svelte

Props in Svelte work similarly to how they do in other frameworks: they allow you to pass data from a parent component to a child component. To accept props in Svelte, you define them as variables with the export keyword:

<script>
  export let name;
</script>

<h2>Hello, {name}!</h2>

You can pass the prop like this:

<ChildComponent name="Svelte" />

4. Bindings and Events

Svelte makes it easy to handle user input by binding form elements to variables. This two-way data binding ensures that the UI and JavaScript logic are always in sync.

<script>
  let name = '';
</script>

<input bind:value={name} placeholder="Enter your name" />
<p>Your name is {name}</p>

Transitioning to SvelteKit

Now that we’ve covered the basics of Svelte, let’s talk briefly about how SvelteKit expands on this. SvelteKit is the application framework built on top of Svelte, which adds essential features like:

File-based routing: Automatically creates routes based on your project’s file structure.
Server-side rendering (SSR): Builds pages server-side to improve performance.
Static site generation (SSG): Pre-renders pages into static HTML for blazing-fast load times.
Client-side hydration: Merges the static HTML with client-side JavaScript to make your app fully interactive.

Next Steps

In the next installment, we’ll dive into these rendering strategies (SSR, SSG, and CSR) and show how SvelteKit seamlessly switches between them depending on your needs.

If you're ready to explore more advanced SvelteKit topics or have any questions, join us over in The Developers Lounge on Discord. We’ve got a mix of beginners and seasoned developers eager to help out. Let’s dive into SvelteKit together and build something awesome! Join here.

File It Away: Groceries, Persistence, and Bash Mastery

Jimmy McBride — Thu, 26 Sep 2024 21:10:06 +0000

Welcome to the bonus 4th installment of our Textual Healing series! By now, you’ve already got a handle on some essential text manipulation tools, but today we’re taking things up a notch and talking about persistence—no, not in the “keep going when things get tough” sense (though, kudos if you’re doing that too). We're talking about file storage and how to keep your data around even after your script finishes running.

So buckle up—today’s goal is simple: learn how to take user input, store it in a file, and manipulate that data over multiple script executions. As an example, we’ll be building a script to manage a grocery list. We’ll show you how to add items, delete items, and persist the list in a file.

Let’s get into it.

Step 1: Taking Input from the User

First up, we need to capture what the user types. In Bash, this is super easy thanks to the read command. Let’s start by asking our user for an item they want to add to their grocery list:

echo "What item do you want to add to the grocery list?"
read item
echo "You added: $item"

Easy enough, right? Now we’re going to save that to a file, because let’s be honest—no one has the time to retype their grocery list every time the script runs.

Step 2: Storing Input in a File

To keep our grocery list persistent, we’re going to write each item into a file called grocery_list.txt. Every time we add something, we’ll append it to the end of the file.

echo "$item" >> grocery_list.txt
echo "$item has been added to your grocery list."

What’s happening here? The >> operator appends whatever $item holds into the grocery_list.txt file. If the file doesn’t exist yet, Bash will create it for you. Persistence: achieved! 🎉

Step 3: Displaying the List

Let’s get fancy. Now that we’re adding items to the file, it would be helpful to display the full list back to the user.

echo "Here's your current grocery list:"
cat grocery_list.txt

This reads and outputs the content of grocery_list.txt so you can see everything you’ve added so far. And since we’ve already covered the power of cat in previous installments, you know how useful this is for text manipulation.

Step 4: Deleting an Item from the List

Now, let’s take it up a notch. What if you accidentally added "ice cream" to your list and, out of guilt, you want to remove it? Let’s build a way to delete items from the grocery list. First, let’s display all items and let the user choose which one they want to remove.

echo "Here are the items in your list:"
cat -n grocery_list.txt
echo "Enter the number of the item you want to delete:"
read number

The cat -n command prints the list with line numbers, making it easy to pick an item to delete by its number. Next, we’ll use sed to remove the item based on that number:

sed -i "${number}d" grocery_list.txt
echo "Item $number has been removed."

The ${number}d in sed tells it to delete the specified line. The -i flag makes the changes directly in the file. Warning: Use sed -i with caution—there’s no trash bin in Bash, so once it’s deleted, it’s gone forever!

Step 5: Making It All Work—Putting It Together

Here’s a simplified version of what we’ve covered so far. We’ll make a script where the user can add grocery items, view their list, or delete items. Here’s how it looks:

#!/bin/bash

grocery_list="grocery_list.txt"

while true; do
    echo "What do you want to do?"
    echo "1) Add an item"
    echo "2) View the list"
    echo "3) Remove an item"
    echo "4) Quit"
    read choice

    case $choice in
        1)
            echo "What item do you want to add?"
            read item
            echo "$item" >> "$grocery_list"
            echo "$item has been added."
            ;;
        2)
            echo "Here’s your grocery list:"
            cat "$grocery_list"
            ;;
        3)
            echo "Here’s your grocery list:"
            cat -n "$grocery_list"
            echo "Enter the number of the item you want to delete:"
            read number
            sed -i "${number}d" "$grocery_list"
            echo "Item $number has been removed."
            ;;
        4)
            echo "Goodbye!"
            break
            ;;
        *)
            echo "Invalid option. Try again."
            ;;
    esac
done

This script gives the user full control over their grocery list—adding, viewing, and removing items as they please. Now it’s your turn to take these concepts and build something cool, like a to-do list or any other interactive CLI app. You’ve got the tools; go build!

Step 6: Making Your Script Executable

Before you run your script, you’ll want to make sure it’s executable:

chmod +x your_script_name.sh
./your_script_name.sh

And there you go! Now your script is ready to use on-demand without needing to call bash every time.

Conclusion

With this bonus installment of Textual Healing, you now have the power to capture user input, store it in a file, and manipulate that data across multiple script runs.

If you enjoyed this post and want to dive deeper into Bash, CLI tools, and Linux wizardry, join us over in The Developers Lounge! We’ve got a fantastic community of developers who love to code, tinker, and help each other grow. Whether you’re a beginner or an experienced dev, we’d love to have you! Join here.

Forem: Jimmy McBride

[Boost]

How to Sell Your Skills with a Small Project

Very cool project!

Process Mapping Tool

Understanding Nodes in Godot (For Absolute Beginners)

🧱 What Is a Node, Really?

🌲 The Scene Tree

🧩 Different Types of Nodes

🪜 Parents, Children, and Hierarchies

🧱 Scenes: Reusable Node Trees

⚙️ Adding Behavior with Scripts

⚡ Signals: How Nodes Talk to Each Other

🕹️ Example: Building a Simple Player

Scene Tree

GDScript Version

C# Version

🧠 Wrapping Up

From GDScript to C#: A Practical Guide to Converting Your Godot Scripts

🧩 Basic Syntax Differences

⚙️ Export and OnReady Variables

📡 Signals — The C# Way

🌳 Node Access and the Scene Tree

🌍 Autoloads and Global Classes

🔁 Lifecycle Methods

🎮 Input Handling

🧱 Collections and Loops

⏳ Async / Await vs Yield

🧠 Common Gotchas

⚖️ When to Use C# vs. GDScript

💬 Final Thoughts

Self-Host Your Digital Empire: 4 Open-Source Essentials

Coolify

AppWrite

Plausible

SvelteKit

Conclusion

I Survived a Massive DDoS Attack and Made My Server Bulletproof

Firewalls! 🔥🔥🔥

Join The Community

Be Real: How to Use AI Writing Tools and Stay Authentic

AI-Generated Content vs. Human-Generated Content

Using AI To Edit Your Human-Generated Content

Do I Still Use AI?

Using AI Moving Forward

Join The Community

The Ultimate Dev.to Hacks To Skyrocket Your Blog's SEO & Traffic

Canonical Links: Why You Need Them

Why Canonical Links Alone Aren't Enough

Sitemaps: Your Fast Pass for Indexing

Google Search Console: Your Control Center for Indexing

The Full SEO Picture

Wrapping Up: SEO Done Right

Build The Perfect Tech Blog With SvelteKit

Step 1: Setting Up SvelteKit and Tailwind CSS

Step 2: Setting Up Markdown Parsing with mdsvex and Shiki

Step 3: Creating Blog Posts in Markdown

Example Post: src/posts/first-post.md

Step 4: Fetching and Displaying Blog Posts

Why We're Using export const prerender = true

Step 5: Displaying Individual Blog Posts

Conclusion

Svelte the Difference: Solving Web Challenges with Ease

File-Based Routing

Dynamic Routes

Layouts in SvelteKit

Rendering Strategies: SSR, SSG, CSR

1. Client-Side Rendering (CSR)

2. Server-Side Rendering (SSR)

3. Static Site Generation (SSG)

Configuring Rendering in SvelteKit

Other Problems SvelteKit Solves

1. Pre-fetching

2. Built-In Data Fetching with Load Functions

3. Error Handling

4. API Routes

5. SEO Optimization

Conclusion

SvelteKit Basics: A Crash Course

What is Svelte?

Example Post: `src/posts/first-post.md`

Why We're Using `export const prerender = true`