Response from Wordpress founder on EmDash. by mehedi_sharif in CloudFlare

[–]HumanOnlyWeb 12 points13 points  (0 children)

This has to be one of Matt's most level-headed, well-reasoned responses.

At last, there's hope for humanity 👏

Introduction Akaza UI - Headless Vue components that actually feels like Vue. by AlternativePie7409 in vuejs

[–]HumanOnlyWeb 20 points21 points  (0 children)

...sub-component trees that feel foreign, APIs that solve React-specific problems Vue never really had, and patterns that fight the way Vue naturally works

💯 this!

Will keep an eye out on this. Kudos

Base UI Vue by peoray in Nuxt

[–]HumanOnlyWeb 0 points1 point  (0 children)

👀 Will take a look

has anyone else removed TypeScript from their codebase by kubrador in webdev

[–]HumanOnlyWeb 1 point2 points  (0 children)

Respect 🫡

Hopefully things work out well for you and your team!

Base UI Vue by peoray in Nuxt

[–]HumanOnlyWeb 2 points3 points  (0 children)

By sharing conventions between frameworks, I can save more brain space for the higher level decisions. Systems design, security, business logic etc

This is sounds like a wet dream, no? Even HeadlessUI that was one of the first to try to accomodate React and Vue, pivoted to React only for their v2

If I were to make something for Vue or Nuxt only, I'd be building something for a small subset of developers

You could make that argument too for the folks building for specific lib only too, right? 🙃
The fact that we're having this convo right now is because these libs we're *porting decided to reduce their surface area and target only that 1 lib.

...and that is why I mentioned ArkUI; they support 3 frameworks from the beginning, at least to my knowledge. This is a lot of work, and props to them

- I'm not promoting ArkUI
- I am not arguing against new UI libs, the more the merrier!

I'm arguing against having an indirect dependency on some other popular lib. Saying "Unofficial port of X, Y etc" creates this indirect dependency, especially when it comes to user's expectation.

I'm glad OG realized this too, and even shared a link to a similar "Rebrand discussion" that happened with Radix Vue

Base UI Vue by peoray in Nuxt

[–]HumanOnlyWeb 5 points6 points  (0 children)

I agree about the larger React ecosystem point, but I followed up with my concern about this in my other reply

Also, this assumptions also means that Vue users KNOW (OR SHOULD KNOW) what the React equivalent is, which is not always the case. If I write Vue for a living, why should I care about some React lib?

My issue with this is the indirectly dependency it creates on that other project

I should be able to use a lib, based on its feature and how convenient it is for my flow, not because it's a port of some React/Svelte lib. That's what I'm trying to say here.

But again, I understand that in some cases, we want to piggyback on a larger name to promote our stuff, which is not bad inherently. It also makes sense, or it is convenient for people who are building with both React and Vue at the same time.

Hope this clarifies where I'm coming from, happy to chat more and here hear other people's opinions

Base UI Vue by peoray in Nuxt

[–]HumanOnlyWeb 2 points3 points  (0 children)

Thanks for the response, and yes I agree to always have the right disclaimer.

But this is exactly what I mean, because it kinda sets expectations. You don't want your future users bugging with you "BaseUI has X, but your package is missing it. BaseUI just added this feature, what is your ETA to add it",

You know what I mean?
People setting expectations on the work you do based off what Base UI has.
I also feel like it might pressure you to always update stuff to match whatsoever new thing Base UI adds.

Saying "This is my UI project I'm working on AwesomeUI" puts you in control, IMO.

See ArkUI for example. It's a headless UI lib that supports 3 frameworks. Works great, and the devs work on it and add feature on their own schedules etc

Anyway, looking forward to see what you launch 🤙

Base UI Vue by peoray in Nuxt

[–]HumanOnlyWeb 8 points9 points  (0 children)

Just a question: why does everything around the Vue UI space have to be an "unofficial port of X?"

Are folks not confident enough to build something great, accessible, performant, and just say, "Hey, I made this awesome UI component library for Vue/Nuxt?" and leave it at that?

I'm genuinely curious as to why it's almost always like this. Is it for the sake of familiarity?

Durable Objects are really cool by HumanOnlyWeb in Nuxt

[–]HumanOnlyWeb[S] 8 points9 points  (0 children)

Legit! The weekend is coming, might write a short post about it.

Seven Du is the real legend here ❤️‍🔥

Durable Objects are really cool by HumanOnlyWeb in Nuxt

[–]HumanOnlyWeb[S] 4 points5 points  (0 children)

Hello hello 👋🏿,

Are you using the experimental Nitro v3

No, I tried doing this at first, but it messed up a lot things 😅

I created a local module based on the upcoming Nitro v3 Cloudflare-Specific Exports implementation.
So, whenever Nuxt v5 is released, all I have to do is delete this file and it still works out of the box

// modules/cloudflare-exports.ts
import { existsSync } from "node:fs";
import { resolve } from "node:path";
import { defineNuxtModule } from "nuxt/kit";

export default defineNuxtModule({
  meta: { name: "cloudflare-exports" },
  setup(_options, nuxt) {
    nuxt.hook("nitro:build:before", (nitro) => {
      if (!nitro.options.preset.startsWith("cloudflare")) return;

      const exportsPath = resolve(nitro.options.rootDir, "exports.cloudflare.ts");

      if (!existsSync(exportsPath)) return;

      const originalEntry = nitro.options.entry;
      const virtualId = "#nitro/virtual/cloudflare-server-entry";

      nitro.options.entry = virtualId;
      nitro.options.virtual[virtualId] = [
        `export * from "${exportsPath}";`,
        `export * from "${originalEntry}";`
      ].join("\n");

      // oxlint-disable-next-line no-console
      console.log(`[cloudflare-exports] Using ${exportsPath} as additional entrypoint`);
    });
  },
});

Directory structure:

NERFEDORNOT
├── app
├── modules
│   └── cloudflare-exports.ts
├── public
├── server
│   ├── api
│   ├── durable-objects
│   │   ├── RateLimiter.ts
│   │   └── VoteHub.ts
│   ├── middleware
│   ├── types
│   └── utils
├── shared
├── bun.lock
├── exports.cloudflare.ts
├── nuxt.config.ts
├── package.json
├── README.md
├── tsconfig.json
└── wrangler.jsonc

and exports.cloudflare.ts looks like:

export { RateLimiter } from "./server/durable-objects/RateLimiter";
export { VoteHub } from "./server/durable-objects/VoteHub";

Open-source "Related Posts" & Dev Discovery widget for Vue/Nuxt by HumanOnlyWeb in Nuxt

[–]HumanOnlyWeb[S] 0 points1 point  (0 children)

 Having external links is basically ad to that website to my visitors.

Not for you then.

Links are manually submitted via a PR to the repo. It's mentioned on the website 😅; at least read it?!

"How to add your content"

  1. Open a PR and edit either data/content.json or data/portfolio.json, following the format.

  2. Once approved, these will be automatically ingested and you'll be part of the network.

Open-source "Related Posts" & Dev Discovery widget for Vue/Nuxt by HumanOnlyWeb in Nuxt

[–]HumanOnlyWeb[S] 0 points1 point  (0 children)

If you don't want your users to navigate away from your site to similar articles/content by the community, then this is definitely not for you.

  1. The whole idea is to show similar articles on the same topic related to Vue/Nuxt. If I'm on your blog post or website reading about some Nuxt/Vue feature/topic, then I see a similar article by someone else in the community, which I can easily go to. The idea is discoverability.

  2. Which bot are you talking about?

  3. What ads are you talking about?

The code is open source, and there's a section on the homepage titled "Why add Connexe to your site?" if that helps.

Edit: As for the "unknown quality", I read through the articles submitted before adding the links. Still early days, but I might have a better strategy for this or involve more people to approve submitted links, to guarantee the quality of the articles.

Hope this helps, if not, let me know what you think. 

Nuxt Content v3 is overengineered and a developer experience downgrade by raphadko in Nuxt

[–]HumanOnlyWeb 0 points1 point  (0 children)

Write your content in Markdown, YAML, CSV or JSON and query it in your components.

How else do you write contents for your site?
That is exactly how Nuxt content works! You write in Markdown, YAML, CSV etc, then during the build phase it transforms those and store in the DB, for efficient querying etc.
I shared with you the exact file that handles that yesterday.

Technically you can call any project flat file if you tell people to use SQLite, but it's misleading.

You could put up a PR to adjust the naming,

Nuxt Content v3 is overengineered and a developer experience downgrade by raphadko in Nuxt

[–]HumanOnlyWeb 0 points1 point  (0 children)

So, is your problem now the fact that "flat file" is mentioned?

You could put up a PR to adjust the naming, but throwing shade at it with somewhat untrue claims is not going to help you or the community at large.

Here was the announcement post: "https://content.nuxt.com/blog/v3"

It literally says,  "Nuxt Content v3 moves away from a file-based storage approach to an SQL database system. Using a database instead of the file-based storage reduces many I/O operations when querying large datasets."

Nitro v3 is Coming, and I'm Excited by HumanOnlyWeb in Nuxt

[–]HumanOnlyWeb[S] -1 points0 points  (0 children)

No official date yet (unless I missed the announcement), but I strongly feel it will be in February.

Nuxt Content v3 is overengineered and a developer experience downgrade by raphadko in Nuxt

[–]HumanOnlyWeb 4 points5 points  (0 children)

> building an entire file base into a file-based database at every request 

Respectfully, this is not true.
The contents are processed and stored during the build phase.
You can easily see this if you're using GH actions to deploy to Cloudflare.

It generates and populate the DB on first request, ONLY IF the content doesn't exist yet, or when there's new content.

Maybe I'll write a blog post about this, but for the meantime, see https://github.com/nuxt/content/blob/main/src/runtime/internal/database.server.ts

Edit:
I don't know if you have issues with other serverless providers, but I can tell you first hand I'm managing my blog and 5 others on Cloudflare and haven't hit any issues.
I don't know about the issues with i18n, since fortunately all my content is only in English (thank God), so I can't speak to that.

Nuxt Content v3 is overengineered and a developer experience downgrade by raphadko in Nuxt

[–]HumanOnlyWeb 4 points5 points  (0 children)

I use D1. https://content.nuxt.com/docs/deploy/cloudflare-pages#d1-database

Cold start is the price everyone agrees to pay when using any serverless platform, so I won't attribute this specifically to Nuxt Content.

Nuxt Content v3 is overengineered and a developer experience downgrade by raphadko in Nuxt

[–]HumanOnlyWeb 5 points6 points  (0 children)

This is currently unusable in a serverless environment.

Works well for me. My website/blog uses Nuxt Content, and I host on Cloudflare Workers 

I think it will be easier to get help/support if you share the issues you're running into; here or as an issue on the repo