DEV Community: James 'Dante' Midzi

The 'AI' Problem Noone Is Talking About

James 'Dante' Midzi — Tue, 25 Aug 2026 08:35:11 +0000

We are very deeply into 'AI' and the environment it has created. Over the course of these several years there have been a number of discussions, debates on ethics and the proliferation of these technologies. It started with speak of them taking jobs - people getting fired, companies replacing humans with them. And more importantly the creativity side and generative 'AI'.

To add to that, the legal debates on rights and who own what is created by these generative systems.

More recently, the effect this technology has had on the open-source world.

However, throughout all of this what I've never seen being talked about most is the core that powers these LLMs, what enables them to be functional and to exist, and that is the data.

For your ChatGPT, your Claude, your Gemini; for your Deepseek. For all of them to function and give you answer as 'quickly' as you assume, it requires data - large swathes of data. But there is only so much data one can feed into an LLM to train it. As of a certain point these companies had scrapped most if not all of the internet to train their model - some of it legally and some illegally. It had gotten to a point where the 'AI' was being trained on data from the 'Ai' creating a recursive loop.

So where does a multi-million dollar company turn to in order to satisfy the endless hunger of the beasts they created? Well, to books of course. Physical books.

A good number of you would not know about this because books, in the current climate, are not something that makes headlines. Also, a lot of you don't care about books anymore. And this is why I have written this - the books.

How Are Books Relevant?

Remember I mentioned legal battles over 'AI'? That's where books come in. If these companies were truly altruistic, the would have gone the legal route, gotten the rights, paid whichever party had ownership of the material they wanted to use. Buuut, as has been evidence - and the reason for the legal battles - they have been scanning and stealing content they have not licensed.

For the books they have now turned to, they would also have to pay royalties and licensing fees...

In the backdrop of legal battles over ownership and who owns what is created by 'AI', books were being destroyed.

I doubt any of you would be aware of this as unless you explore, the only 'AI' you know is ChatGPT. But let me bring your attention to Anthropic and what its been doing...

Anthropic's Destruction of Books

So as to not pay the fees and interact with the authors, Anthropic went about procuring old books, scanning them in a destructive meaner. In an effort to improve its LLM, in an initialve they called "Project Panama”

And I quote:

Project Panama is our effort to destructively scan all the books in the world.

Why do this you may ask? I have already mentioned why, but let me elaborate further.

Anthropic could have secured copyright permission to use existing e-books. This would have required going through the proper channels and engaging with the authors - something the co-founder described as 'tedious'. They had already pirated some sources already which resulted in a large settlement. So, when going about it legally became 'complicated', they turned to destructively scanning books.

You can read more about the whole issue here

Of course they would rather destroy printed copies than work with their authors

The Loss Of Historical Data

A lot of the books being scanned and destroyed are one of a kind, can't be replicated. Once they are gone, they are gone. The only remaining record would be locked in Anthropic's servers. They have no obligation share what they have scanned, and most likely won't. That will make it even more difficult to find and get actual sources from the original authors of said information. All that would be left is whatever output the LLM has produced from its training

What Happens When There Are No More Books?

We have already seen examples of what that looks like. Every single piece of physical media that was made digital exists at the whims of the company that made it so, and when that licensing runs out. In particular, the PlayStation situation - where hundreds of movies 'purchased' on the platform are slated for deletion.

Well a lot of you might not care now. You will later on when you can't get actual sources. When all you have to look for is an LLM run by a company that can revoke your access at their whim, at their own discretion. You can't say anything about it because they're in control .

In a world where all the physical books are gone and one company or another controls your access to those digital copies, nothing stops them from modifying the books, taking the books from your control, or just denying you access.

That is not a concern if you have physical copy of the book.

Wrapping Up

Do I have a solution? I don't. I am not in a position to solve these things, not in a high enough position of power. All I can do is do what I've always been doing: try to bring awareness to what's happening while you are asking ChatGPT what the square root of a triangle is.

All of this conveniently ties into the current push for digital ID that has been ramping up as of late. Once that goes online and the media is also online, the ID could be used to stop you from reading what they don't want you to. I say this in full knowledge that a good number of you don't read anyway, but for the ones that still do...

The domino effect concerns me a great deal...

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. My email and DMs are always open; if you want to chat or collaborate on something, shoot me a email

Where you can get hold of me:

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Are You Crippled By Your Preferences

James 'Dante' Midzi — Mon, 17 Aug 2026 08:03:25 +0000

This article directly follows after the one I wrote about types.

I caught a replay of a live stream the other day. During the live stream the developer was testing out Svelte, specifically the Svelte version of shadcn; svelte-shadcn.

And throughout the video all he was doing was comparing the official shadcn website to the svelte-shadcn one. To me this was kind of strange because these are two different projects. Yes, one might take inspiration from one from the other but they are not the same things.

Then he went on to say the reason why he never used Svelte is because he wants to use shadcn libraries. They're not supported by Svelte, and that got me very worried. You refuse to explore another technology because this one styling thing is not there? 🤔

I believe as a developer you should be fluid.

You shouldn't be crippled or locked in by one thing or the other. To me from the video and what he was doing, he's so obsessed with shadcn to the point that anything that doesn't support shadcn he can't use, i.e. Svelte.

From what I understand when you were setting up the project with shadcn, there is a command on the website where you can just click a command and paste it and then it sets up the project and installs shadcn.

He tried to do same on the svelte-shadcn website; it didn't work. He then said, "This could be an easy thing to do."

I'm then thinking, "But it's not the same thing. You can't be expecting this one developer who ported some shadcn to svelte to be able to keep on track with every single thing shadcn is doing." It doesn't make sense particularly with the climate we're in right now.

As of writing this svelte-shadcn has implemented that new project create flow

Preferences As A Crutch

This got me to wonder specifically about myself: is there anything that I'm too locked into that exploring something different is not possible?

If you've been following my articles for any point in time, you know that I useTYPO3, I've explored Eleventy, I've used Astro, I've used React, I've used just about everything. Not because I'm undecided, but because I want to be knowledgeable about the things people are using. To do that, I get out of my own way and learn, broaden my horizons, to not be locked into one thing, to not be crippled by my preferences.

Yes of course I've got things I prefer but that doesn't stop me from using other things, which is in direct contraste to that Youtuber I was watching. He's crippled by his preferences. If something doesn't have shadcn in, he can't use it because it takes too much time and it uses his tokens, as he says - this bring back a things I mentioned in the previous post. This dependence on LLMs

It's one of those lessons that I learnt early on that you're not going to have one-to-one replication from one technology to the other.

You're going to have to mould, not even mould yourself, but be fluid enough to change and understand what the technology wants and do what it wants, not what we're forcing it to be whatever you're used to.

Wrapping Up

Well initially I didn't think this was a problem but this has brought up several questions. Now I'm opening it up to you.

Do you not use a technology because it doesn't support the things you used to? Do you?

Are you that close-minded that you can't adapt?

If you are I don't think you can call yourself a developer.

In my head as a developer, you're supposed to be able to learn anything you're driven to. Your driving tenet should be to learn. If you don't understand something you take the time to learn what it wants not what you want.

Let me end this by saying:
Styling Has Existed Before Shadcn, It Will Exist Long After.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. My email and DMs are always open; if you want to chat or collaborate on something, shoot me a email

Where you can get hold of me:

Strict Types Won't Fix Your Lack of Understanding

James 'Dante' Midzi — Wed, 01 Jul 2026 17:24:18 +0000

In development circle I am what would be considered a mid/senior developer. I have been in the trenches, seen the rise and fall of technologies. Seen the prophecies of doom and gloom with new things that showed up. Been a part of the ebb and flow of it all. My training, my initial training came in C, C++ and Java. So I would like to think I know what I am talking about when I am sceptical about things.

An interesting thing I have come across over the years, is this need to enforce types on languages that are dynamic and pride themselves on that. While this wasn't an issue prior, it has become an increasingly worrying trend with current day developers. You come from a strictly typed language to a dynamic one and upon encountering something you don't understand, you assume adding types would fix the problems you have.

Learn The Language

As a developer it should be within you to want to learn, to strive for it. The need for improvement should be on of your core tenets - to want to be better. You wanting a language to have strict typing because that is what you are used to is a failure on your part.

The Offenders

JavaScript/Typescript

Arguably the worst of the offenders. This has been going on for as long as I can remember.

I recall somewhere saying, "The war is over, typescript won". And I laughed, audibly, out loud. How does a super-set of another language win anything. It also wasn't a win, more a pushing hard for it to the point that the people against simply stopped arguing and moved on to building in.

Honeestly, you can't tell me this is better:

import { BaseRecord, DataProvider, GetListParams, GetListResponse } from "@refine/core";

import BaseRecord. DataProvider. GetListParams. GetListResponsel from
"arefinedev/core";

export const dataProvider: DataProvider = {
    getList: async <TData extends BaseRecord = BaseRecord>(f resource ):
     GetListParams): Promise<GetListResponse<TData>> => {
        if(resource !== 'subjects') return [ data: [] as TData[], total:

        return {
            data: [],
            total:
        }
    }
}

Python

In all my years of development, I never thought Python would join this conversation. But here we are. For all intents and purposes, type hints in Python were meant to be optional. But it seems to me these hints are now becoming mandated.

Python is smart enough to infer the type of your variable and return type of your functions. What are we doing here people?

The AI Argument

"I don't need to understand the language, the AI will do it for me"

Sure, that might be true, but what happens when something breaks and you have no clue why? What happens to your AI generated strongly typed code that you can't parse? You'll feed it to another AI as well?

Also, I am sure you have noticed that these companies have jacked up their prices. This is going to continue, and because you have offloaded your thinking to some model you are going to pay.

My Stance

Now, I am not saying no to types, far from it. What I am saying is learn the language and its nuances. Learn what makes it special, before you instantly decide this isn't working and types are needed. What I constantly here is "types will help". Help what? - When you don't understand the underlying language?

There is a time and place for types, and that time and place is when you have learned and understood the language. Only then will what you are enforcing types on matter and make sense.

I understand the necessity of types and I also understand when they are being used a crutch.

A Small Shout out

In my fatigue of all the frameworks and all the gospel of types, I was fortunate to come across Angela Holden, who built a site for her 30 days of Vanilla JavaScript series - a commitment she undertook to improve her JavaScript, a stream everyday for 30 days. She has been a developer for over 13 years and she has chosen to work on the language, to practice, to get better at it. To understand its nuances.

Here is the site she was working on during the 30 days. Quite impressive if I do say so myself.

Wrapping Up

I am concerned, not for myself but for the ones that come after. The ones that will not have that sense of curiosity and wanting to understand because they have been spoon-fed everything.

I haven't been writing as much as I have been navigating this new landscape we find ourselves in, as well as other pressing mattters in my private life. I can't say when next I'll publish something, but be assured I am watching and paying attention to it all.

A lot of you now think fundamentals don't matter anymore, I would argue they are more important than ever.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. My email and DMs are always open; if you want to chat or collaborate on something, shoot me a email

Where you can also get hold of me:

Crypto Forge - Embracing Nuxt

James 'Dante' Midzi — Tue, 06 Jan 2026 15:58:39 +0000

I was out of commission for several months. During my time away I got time to refocus, recentre and work on my writing.

When I was finally cleared one of the things I did was refresh my memory in several technology I had settled on. One of them was Nuxt, as I outlined in this article .

I am here to present to you Crypto Forge- an app that lists cryptocurrencies and allows you to sort them in different ways.

In essence it is a migration of Brad Traversy's project, Crypto Dash that was in React.

Why Recreate Instead of Building Something New?

As I mention, I needed a refresher on a lot of the tools I had chosen. Rather than come up with a whole new ides, to dip my toes back in, I thought migrating something that is already working would be simpler than starting something completely from scratch. I do have ideas.

What I Learnt

This exploration offered several learning opportunities, and entailed understanding what React was doing and translating that to Vue/Nuxt.

API Routes For Data Fetching

Initially when I stated, I tried to fetch the data directly in the page. Upon further reading, and advice from the discord I learnt that it was recommended to use the server folder and API routes to handle fetching of data.

This helps in better managing server only parts of a Nuxt application. Using the server folder also helps in scalability and structuring of endpoints.

While in this project I only made use of GET requests, in another one I am working I made full use of all the HTTP methods - it's a bit more complex.

My usage looks like this:

//server/api/coin.get.js
export default defineEventHandler(async (event) => {
    const query = getQuery(event);

    return await $fetch("https://api.coingecko.com/api/v3/coins/markets", {
        params: {
            vs_currency: "usd",
            order: query.order ?? "market_cap_desc",
            per_page: query.per_page ?? 10,
            page: query.page ?? 1,
            sparkline: true,
        },
    });
});

NOTE:
Ideally the URL would be in an environment variable

Composables To Avoid Logic Duplication

A composable is a reusable function that performs some kind of logic. Say you needed to fetch user data for each page they visit on your app, rather that making that call every time, you would create a composable that does that.

For example:

//src/composables/useUser.js

export const useUser = () => {
  // Shared, SSR-safe state
  const user = useState<any | null>('user', () => null)


  aaync function fetchUser(){
      const { data } = await useFetch('/api/user', {
        credentials: 'include', // important for auth cookies
      })

      user.value = data.value
  }

  return {
    user,
    fetchUser
  }
}

I made use of a composable to fetch the coin data. That piece of code is too long too share, you can view it in the repository though.

What's Next?

I have already started work on my next project using Nuxt. I am still contemplating whether to make it public or not. Broadly, I need to get a authentication and connecting to the database fully functional. So in the next coming weeks, I just might release it to the wild.

I am still fixing issues with my policies and row level security.

Wrapping Up

This was a fun exploration to get me back into the swing of things. I got to learn new ways of doing things; which I would argue are better than the other technologies I have explored.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Laravel is How Development Should Be

James 'Dante' Midzi — Mon, 31 Mar 2025 07:11:42 +0000

I have not been doing that much writing. Not because I've nothing to write about, no. It's because I have been head down, silent and learning.

I have been learning Laravel. If you read this article of mine you will recall I said I wouldn't reach for Laravel because I already use TYPO3. I had to walk back that statement when I realised while I have TYPO3, it is better suited to more involved projects.

What changed? Well, I have a biggish project I am working on and I landed in a situation where SvelteKit wasn't sufficient and TYPO3 was too much. I needed a midpoint - and I was not going to go back to Nextjs.

Laravel

Instead of trying to rattle my head with something new, I chose to leverage the PHP that I already know. On another journey I went, and what a wondrous one it turned out to be.

Why Laravel Works?

It just does. In encounters that I have had with it, it shows a lot of thought went into creation of the framework. I don't know how to explain it, but it just does. Most things you may want to do, Laravel most likely has an in-built solution. Batteries included, I hear people say.

Authentication and Authorisation

A thing that we all have to handle as developers is auth. In previous times I have always left this until the end because a number of the options were a headache to deal with.

This is not the case with Laravel. You could choose to setup up the authentication flow on your own with code that sort of looks like this:

public function store()
    {
        //validate
        $validatedAttributes = request()->validate([
            'first_name' => ['required'],
            'last_name' => ['required'],
            'email' => ['required', 'email'],
            'password' => ['required', Password::min(6), 'confirmed'],
        ]);

        // create user
        $user = User::create($validatedAttributes);

        // log in
        Auth::login($user);

        //redirect
        return redirect('/dashboard');


    }

Or you could pick on of the starters that handle this for you. Some of them adding a few features to the process.

The same goes for authorisation. Based on how you want the access to things to be be you can specify the authorisation rules on the specific routes, app-wide or on individual controllers.

// auth on a route
Route::get('/jobs/{job}/edit', [JobController::class, 'edit'])
    ->middleware('auth')
    ->can('edit', 'job');

// the policy that manages it
 public function edit(User $user, Job $job): bool
    {
        return $job->employer->user->is($user);
    }

Database Relations

A thing that has given me trouble when building is database relations. I recall a time on one of the projects I was working on I got stuck trying to define database relations with Prisma. Some of it was because of how new I was at it. But even after I understood what was required the particular process manged to confuse me more.

Laravel on the other hand is intuitive about relations. Yes, you have a couple of places you have to ensure you have handled. But that, I have found makes you consider things more deeply and pay close attention.

Take for example; you have an Employers table and a Jobs table. Each Employer can have many Jobs. For that you would:

Add the relation in the migration file
Define the relations in the respective model files

Code snippets in this article are taken from my Learn Laravel in 30 days repository as well as the final project from that.

Appreciation

I would also like to thank Jeffrey Way for making my journey into Laravel an enjoyable experience. I highly recommend the 30 days to learn Laravel playlist.

What About SvelteKit?

It's a very unfortunate thing really. I find myself in the position of having to walk back on things I said.

A little while after I adopted Svelte, several changes were made that go against the simplicity I have been aiming for. As such, if I am to use SvelteKit now, it would be in the state that I found it in when I started and now. As for the time being, me and Sveltekit are taking a break.

Wrapping Up

I never paid that much attention to Laravel and I regret that. However, at least I have seen the light.

Although, I am not a fan of how the Laravel team are trying to streamline the project creation process. I don't like starters I didn't make is all.

I have been doing a lot of walking back my statements recently, huh?

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

How Svelte 5 Made Me Understand Nuxt

James 'Dante' Midzi — Thu, 27 Feb 2025 10:38:37 +0000

I have gone on a journey. A long winding journey. A journey I could not have foreseen. As it would have it; I am back, once again, announcing my change in methodologies and workflows.

A lot has happened in the world of development and tech; from React and Next.js, to Lucia, to Laravel, to Astro. So much to talk about...

One of those 'changes' has made go back to the drawing board yet again. Something I did not think I would have had to to do for about 3 to 5 years. Yet, here we are; me eating my words. Rather than having to answer question later down the line, I figured it would be simpler for me to talk about and explain my decisions.

The Changes

It all boils down to one thing really. One thing that has been made core and I cannot get with it.

Runes - My Friction Point

I have read through the documentation, I watched the release videos. I have explored the new way. After all that, I will never accept the runes syntax. My brain will not find synergy.

This - whatever this way is - is in opposition of all the reasons I gravitated towards Svelte and Sveltekit.

let count = $state(0);
let double = $derived(count * 2)

$effect(() => {
    setInterval(() => {
        elapsed += 1;
    }, interval);
});

I understand all of it, I get what they were trying to accomplish. I just don't like it. It is too indicative of React; and I left React ages ago.

I left the useState and useEffect of React because they wound up complicating what should have been simple. The runes syntax of Svelte feels a little to similar to React and I have no intention of writing that kind of code again. Regardless of how 'better' it may be.

For me there was something elegant about Svelte's $: syntax. It was simple, straightforward and easy enough to understand. It wasn't perfect, but it worked.

Then Snippets...

To be able to have and reuse chunks of code. Sounds cool on paper, but looking at the code and the implementation, it feels too much like a React way of doing things. There are waaaaay to many symbols for my liking. This is horrible to look at:

<script>
    let { message = `it's great to see you!` } = $props();
</script>

{#snippet hello(name)}
    <p>hello {name}! {message}!</p>
{/snippet}

{@render hello('alice')}
{@render hello('bob')}

Nuxt

In an article, where I sang the praises of SvelteKit, I said that I didn't like Nuxt and how it did templating.

With the looming arrival of Svelte 5, I revisited decisions I had made earlier. I realised that a lot of what I was complaining about had to do with my misunderstanding. I got over those misconceptions and learnt, built and migrated some projects.

A few things that finally won me over were:

File-Based Routing: Nuxt implements file based routing, not directory based - I have an article on this. I have always been partial to file-based routing. I only tolerated SvelteKit's directory approach because everything else is simple.
Auto Imports: In most frameworks if you wish to import something into a file, you usually have an import statement at the top. This is not the case with Nuxt
Separation of Concerns: I mentioned this in that same article; how I was not a fan of Next.js placing everything in a single directory. Nuxt doesn't have that problem - everything has its specified place
- Pages
- Layouts
- Middleware
- Server
Modules: So the Nuxt people have modules, modules upon modules to things you may want to add to your project; icons, SEO, sitemaps, fonts. Nuxt probably has a module for that. Reminds me of Astro integrations - I love those.

I was wrong about Nuxt, I admit that.

Wrapping Up

I guess that's the beauty of being a developer and an adult; the ability to choose what I use and what I don't. If I am not happy in what I am doing and what I am doing it with, I will rarely ever invest that much commitment into it - this is where I have arrived with Svelte - I am not happy, I feel I am moving backwards.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

You Don't Need The Flex

James 'Dante' Midzi — Mon, 27 Jan 2025 12:04:52 +0000

I find it very amusing that this is going to be my first post of the year. But it has bothered me enough that I must speak about it.

No one can deny the godsend that tailwind has been. We are able to prototype faster and get things done quickly.

I have noticed in the upsurge of Tailwind, has come with a forgetting and overlooking of some properties inherent in CSS and HTML.

Block and Inline Elements

Yes, I am afraid we have to go there...

Block-Level Element

I actually fail to understand how people forgot about the block element aspect of HTML. I see someone doing this:

<div class="flex flex-col">
    <p>One</p>
    <p>Two</p>
    <p>Three</p>
</div>

And all they wanted to do was have elements one after each other - stack them. They already do that! That is what HTML inherently does.

Block-level elements always start a new line.

Yes, of course I understand there are certain instances where you want your element to only take up as little space as possible - what flex does - but paying attention to what they have done, that is rarely the case.

Have a gander a some block elements

<div>    <p>    <main>    <section>    <header>    <nav>    <h1>-<h6>

To quote something Kevin Powell said (I am paraphrasing):

"Don't undo the styling and then end up redoing it again. Use the HTML to your advantage"

Inline-Level Element

For posterity, it is only right I talk about inline elements as well. In HTML, there are certain elements that are not block. These elements only take up as much width as necessary. As such you can place them side by side - they do not naturally stack.

Some inline elements you are familiar with:

<a>    <img>    <input>    <span>    <button>

Wrapping Up

So next time you are trying to stack elements, don't just rush to add flex. Put your elements on the page and see if they stack as you want. Unhand the flex and think about what you want your resulting outcome to be.

And if what I said, doesn't make sense, here is a link to w3schools with examples you can play around with.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Your Constant Quest For Productivity May Be Hurting You

James 'Dante' Midzi — Wed, 17 Jul 2024 12:26:44 +0000

I have been head down working on several things. During the time I found myself accomplishing a lot of what I had set out to. Accomplishing a lot more than I would previously. What changed?

Let me take you on a journey...

A number of the decisions I took towards the end of the previous year began to pay dividend. These included my stepping away from React and that ecosystem. Changing how I go about accomplishing the things I set out to. Elimination of things from my life and avoidance of others.

Anyway, I digress...

Let's talk productivity...

Productivity

You will be hard pressed to not encounter someone talking about productivity this or productivity that. Be it an app, a book or some system that has 'increased their productivity'. Everyone and their grandma is on some tool, some book, some extension or some keyboard shortcuts to increase productivity - and it never ends. There is always going to be something, there is always something and there will always be something.

One of the things I did, or rather didn't do, was stop hunting down tools and methods to 'achieve ultimate productivity'. A realisation hit me; I asked myself; with all this focus on creating the most productive work environment, is anything actually getting done?

Why that question specifically? It boils down to an insight I had while I was reading and taking in the words in my own time. In it, our guide said something that made me stop and think. It was something to effect of:

The only thing you have the power to control is you. And as long as you are controlled by external forces, you will not be free.

Which in turn got me thinking; all this 'productivity' everyone is stuck in endless loops in search of, who is it for? Does anyone really want to be productive, or do they want to look like they're being productive? I have to admit, at a point I was guilty of the latter.

That choice, that simple decision of asking myself; this that I am doing, is it helping me in any way? Is it aiding me getting to my keystones in any way? When I answered those questions honestly, a shift in my mindset occurred. I did away with all the hype and zeroed in on what was important to me.

The More You Look for Productivity, the Less You Accomplish

That was the observation, the conclusion I came to. Every minute, every second spent on trying to and looking for ways to be 'productive' was a minute spent on not getting anything done. Simple as that. There is no hidden tool, special book or supposed system that will get you to be more 'productive'.

The change that needs to happen is you, within you. Once your mind is set right and your focuses are correctly aligned, things will begin to work smoothly and you will attain that 'productivity' that you've been feverishly hunting.

Contrary to what you might have been lead to believe, there is such a thing as too much 'productivity'.

Conclusion

Forget the productivity tools, forget the books, forget the systems. Do the work, accomplish the task. Quiet the noise. Productivity is not some magic pill you can stumble upon, it is a shift in mindset. Wrap your head around that, and stop hunting for magic geese.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Say Hello To shrinkat - A Tiny URL Shortener

James 'Dante' Midzi — Mon, 15 Apr 2024 14:48:38 +0000

TLDR
I made a link shortener. The goal was to learn the Pocketbase API and see if it could be viable for some smaller projects I build in the future.

There is really not much to say here. I wanted to implement an entirely localised solution to building something

Technologies I Used

SvelteKit (of course)
Pocketbase ¹
TailwindCss

What I Learnt

How authentication works with Pocketbase: It's quite different from how something like Supabase handles it.
Data modelling: Being sqlite, the way I had to think about data needed a slight shift in mindset.
Working with the Pocktebase sqlite database: Working with a barebones database was actually really fun.

Here Are Some Screenshots

Here is the homepage:

Here is what a logged in user sees:

Wrapping Up

This was a fun little thing to build. I learnt quite a bit. There is definitely a place for Pocketbase in my off the cuff build.

My one gripe is deploying this database is not simple, not in the slightest. And no, Docker does not count - I do not use those dark arts.

The code

The code for shrinkat is available on GitHub. Fork it, make it your own, create pull requests...

https://github.com/meerkat-collective/shrinkat

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Testing ↩

Rendering External Markdown in Astro

James 'Dante' Midzi — Wed, 07 Feb 2024 14:30:34 +0000

It seems like I'm always writing the same article... 😂

I enjoy Astro, it's a good framework, but there is one thing about it or rather the docs that irks me.

Astro is pitched as a content first framework with native markdown support. That's what they say. However, this isn't completely the case.

When it comes to markdown that is local to your project, Astro does absolute wonders with the rendering and parsing. Your problems arise when you have your markdown from an external source i.e. a CMS. The docs have been structured in such a way that they want you to use local markdown and Content Collections.

But sometimes, your markdown is somewhere else. What is one to do then?

Let's go on a journey shall we? ...

The Scenario

You use Hygraph as your CMS for your articles. You write your articles in markdown, and you can fetch them and all their data. What you want to do is have your articles rendered on your newly created Astro site.

The requirements for this task are as follows:

It needs to be one thing - a package or whatever - that you import and use.
You don't want to have to configure any additional things.

Before I give you the solutions that I think are best, I challenge you to find the solution within the Astro docs. I'll wait...

The Solution(s)

Markdown Component (deprecated)

I fought with this a while back when Astro was still in v1, and in those times, there was a package called @astrojs/markdown-components. That package has long since been deprecated, as such you won't be able to install it.

For reference, this is how that would look (those who read my Displaying Dev.to Post on Your Astro Site article will be familiar with this code.)

<!-- /articles/[slug].astro -->
---
import Markdown from "@astrojs/markdown-component";

export async function getStaticPaths() {
  const articles = await fetchArticles();

  return articles.map((article) => {
    return {
      params: { slug: article.slug },
      props: { article },
    };
  });
}

const {article} = Astro.props;
const {body_markdown}  = article;
---

<div>
    <Markdown content={body_markdown} />
</div>

A wise man once said, "If it ain't broke, don't fix it."

My site has been working well with this package, and because of that, I will not upgrade it to a higher version as I am not in the mood to do the dance again.

Now, let's head on to the stuff that works with newer versions of Astro.

Astro Pub

Repository: https://github.com/astro-community/md

Installation & Usage

npm install @astropub/md

<!-- /articles/[slug].astro -->
---
import Markdown from "@astrojs/markdown-component";

export async function getStaticPaths() {
    ...
}

const {article} = Astro.props;
const {body_markdown}  = article;
---

<div>
  <Markdown of={body_markdown} />
</div>

NOTE: Currently as of writing this, AstroPub requires astro@^3.0.0 to work smoothly.

Thoughts

If I had no choice, but to fight this battle again, this is the method I would choose.

Markdown-it

Repository: https://github.com/markdown-it/markdown-it

Installation & Usage

npm install markdown-it

<!-- /articles/[slug].astro -->
---
import markdownit from "markdown-it";
const md = markdownit();

export async function getStaticPaths() {
 ...
}

const {content_markdown} = Astro.props
---

<div>
    <Fragment set:html={md.render(content_markdown)} />
</div>

NOTE: Markdown-it also requires astro ^3.0.0

Thoughts

I don't like this method. I don't like it because:

I have to declare a variable to store markdown-it.
I have to use the set:html to render the content.
I have to additionally call the render function and then pass my content to it.

Astro Remote

Update: 29 February 2024

After submitting an issue, Nate added the install command.

Repository: https://github.com/natemoo-re/astro-remote

Installation & Usage

npm install astro-remote

<!-- /articles/[slug].astro -->
---
import {Markdown} from "astro-remote";

export async function getStaticPaths() {
 ...
}

const {content_markdown} = Astro.props
---

<div>
    <Markdown content={body_markdown} />
</div>

Thoughts

Astro Remote works very similarly to Astro Pub, and I like that about it.

The Thing About Marked

If you did accept my challenge and looked in the docs, you might have found this section:

Fetching Remote Markdown

The Astro docs recommend marked, but there's some things you have to be aware of with marked.

Marked Site: https://marked.js.org/

Thoughts

Marked informs you on their site that it does not sanitise your markup. Do with that information what you will.

Wrapping Up

Astro - a brilliant little thing. A bit more care with regard to this part of their framework/documentation would be cool. At least as much care as is given to other parts of the docs.

On a steam, whitep4nth3r went on a journey of trying to find this information on stream, her goal was to use things the 'Astro way. In the end, she went with the markdown-it approach.

The stream if you are curious. It's at 3hrs 57 minutes: https://www.twitch.tv/videos/1998429304?filter=archives&sort=time

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Why SvelteKit Will Be My Goto Moving Forward

James 'Dante' Midzi — Mon, 04 Dec 2023 13:00:00 +0000

Allow me to tell you a tale, take you on a journey of how I switched how I work completely and I am probably not going back...

History

Anyone who knows me and has been following my journey is aware that my development focuses consist of:

Python
PHP (TYPO#3)
React/Next.js

What this has allowed me to do is be more efficient at picking the correct tool for the things I'll be trying to accomplish.

The Then

It's no secret that I have been an advocate of Next.js for some time. I even have a short series I did investigating how to integrate it with different Headless CMS. I have done explorations on the features I believed people should know in regards to Next. As such me and Next have been on very good terms for a while.

Breaking Up With Next

Put simply two words - App Router. I am not sure what the team at Vercel was in a hurry to get to, but they rushed this like I've never seen before. With me, if anything is pushed on me that hard, I form a natural aversion towards it; see one of my previous articles.

The Lie of `Stable`

While they may have made it stable now, when a lot of the features of the router were introduced they weren't ready; despite what they liked you to believe.

I could go on and on about the things that were reportedly stable, but that's not the point of the article. What I will do is tell you my main pain points.

Clear boundaries or lack thereof:

One of the things I liked about Next.js was that there were clear boundaries; your pages go here, your assets go here, API routes go here. That is all but gone, with the brunt of the things happening in the app folder.

Having to add pieces of text to change how your file/component works:

This sort of relates to my first point; the adding of 'use client' or 'use server' within a file does not sit well with me. There is something elegant about getStaticProps and getServerSideProps; you knew exactly where your data was coming from and how it would be rendered.

I will not even get started on the actions, sorry server actions.

Yes, I know I can still use Next.js the way I prefer, but the mob makes so much noise I would just rather maintain the project I have the way they are and just not deal with this new way.

The Now

After all the noise with Next.js I went on a journey to find something else that would meet my needs and not lie to me. My journey led me to several options; ones that did things better than Next.js, others not so much. Here is a very brief rundown:

Laravel

Considering I already use PHP in the form of TYPO3. I didn't go that way because I already got a sufficient dose of PHP. Also, I wouldn't randomly whip out TYPO3 for any 'ol project.

Vue/Nuxt

What put me off of Vue/Nuxt was mainly their templating engine. It just didn't sit well with me; the particular way the files in it are written. Also, something about its routing felt iffy.

Solid

This would have been going back to a version of React/Nextjs type framework. I wouldn't learn as much as I would like. Also things would still be abstracted from me, I was trying to avoid that.

Enter Svelte

Long ago, I tried to dabble in Svelte, but that was in my naive and hard-headed days and never took the time to understand what it required of me. Additionally, I tried to do it alongside another person and that did not go well. This time instead, I chose to knuckle down and get into what made Svelte Svelte; the changes in mindset I would need to undertake for this part of my journey.

Finding Synergy

I am not going to lie, the move to SvelteKit was not seamless. A lot of shift in mindset was required

To start the directory-based routing and wrapping my head around the +page.svelte naming convention was a bit confusing to get comfortable with. Afterwards; understanding how working with data was accomplished and what the +page.js and +page.server.js files did, and where I used each.

Understanding those things would aid me greatly in grasping how SvelteKit works and how I should approach my journey with it. With determination in my heart and a vantage point I was aimed at, I went to work.

And then, it clicked!

During the struggling, the change in mindset and embracing the power of native HTML and how SvelteKit leverages that, it clicked. Sticking to it paid off and my new home had been found and solidified.

What I Like About SvelteKit

Native HTML: It strips away the abstraction; no virtual DOM or anything of the kind. It's all just native HTML. Because of that your elements work the way they were intended.
Things are defined clearly:
1. +page.svelte: is your frontend stuff what you see when a page loads. Basically the crux of what a user sees when they visit your site/app.
2. +page.js / +page.server.js: this is where you load data to be displayed on your pages, and where your form actions run.
3. +layout.svelte: this applies styling and/or data to set of routes under the same directory.
4. +layout.js / +layout.server.js: allows you to specify data you want applied to an entire set of routes. In essence, the higher level of your page.server.js
Form actions: With it leveraging the native HTML means it takes advantage of all the functionality already present with forms. This means that nothing is hidden from you; what you can do in a form on a basic page, you can do with Sveltekit.
1. progressive enhancement: since we leverage the default functionality of forms, they will reload the page on a submit. Progressive enhancement gives us the ability to utilise the submit action without making the entire page reload.

Yes sure, Next.js might have now implemented some of this in their new version, but with SvelteKit it feels a lot more thought out and not rushed.

Wrapping Up

All in all, I actually thank Vercel for taking the approach they did. I would not have rediscovered Sveltekit otherwise. In addition, it helps in my goal of stripping away complexity that I talked about in these articles:

And that's the journey; How an advocate of Next.js was not impressed by the direction it took and moved to SvelteKit. Thereby finding a better way, a more honest way, a streamlined way of doing things. A way he is much happier with.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

File-Based vs. Directory-Based Routing: Understanding the Difference

James 'Dante' Midzi — Fri, 24 Nov 2023 18:57:41 +0000

I don't know who did it, and why everyone is suddenly confused by this. What you are calling file-based routing is not what you claim. I will gladly explain.

I am going to use Next.js as an example:

File Based

This is file-based routing:

src/
└── pages/
    ├── index.js
    ├── about.js
    └── contact.js

In the folder that defines your pages, if you are able to create a file in there and it automatically becomes a page (contact, about, services etc) that is file based routing.

File-based routing is a routing where the entry point to your routes is an index file. What that mean is the same way you can have a contact.jsx , you could also make a contact/index.js and these two would do exactly the same with little to no issues.

Frameworks that employ this:

Astro
Eleventy
Nextjs (with pages)s
Vue
Svelte

Directory Based

This is directory based routing

src/
└── app/
    ├── page.js
    ├── about/
    │   └── page.js
    └── contact/
        └── page.js

With this way, there is a defined method of creating new pages i.e a folder with the file name and a special file within it.

When using this way, anything that does not follow this pattern is not regarded a page.

Frameworks that use this

Nextjs (with app)
SvleteKit

A Table To Know What You Are Using

Ask	File-Based Routing	Directory-Based Routing
Can I make a file name as a route and it works?	Yes	No
Can I create a folder with an `index` file and that will become the page?	Yes	No
Do I have a special naming convention for pages?	No	Yes

With this clarification at hand, can you all stop confusing this? You can? Thank you.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn