rxliuli

This is the fourth post in the extension development series. I've just finished writing the seventh one, which will be published gradually after proofreading.

This is the second post in the extension development series blog. I just finished it, so if you find any errors or have any questions, feel free to leave me a comment!

I've been building browser extensions for about a year and created around 20 of them. Thought it might be useful to share what I've learned in a series of posts.

This first one covers the basic concepts - manifest files, content scripts, and how they work together.

If you have any questions or suggestions for future topics, feel free to comment!

That's right, there's a similar comparison between the iOS App Store and Android Play Store. Although the annual $99 fee is indeed expensive, the Play Store requires every app to find 12 users for 14 days of internal testing before submission for review, which is utterly incomprehensible, not to mention the constant warnings about inactive accounts potentially being disabled.

Haven't received it yet.

It appears to have been an accident now - they fixed the issue two hours after I posted on Reddit.

I guess you're promoting something, which could indeed get blocked.

Got tired of dealing with unreadable fetch code when copying from browser DevTools - especially those with long query strings and minified JSON.

Built *Fetch Beautifier* to solve this. It formats fetch requests instantly with `Ctrl+Shift+V`.

*Before:* ```js fetch('https://api.example.com/data?userId=123&type=post&limit=10&o...', { headers: { accept: 'application/json', 'content-type': 'application/json', authorization: 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9', }, body: '{"title":"Hello World","content":"This is a test"}', method: 'POST', }) ```

*After:* ```js const url = new URL('https://api.example.com/data') url.search = new URLSearchParams([ ['userId', '123'], ['type', 'post'], ['limit', '10'], ['offset', '0'], ]).toString() fetch(url, { headers: { accept: 'application/json', 'content-type': 'application/json', authorization: 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9', }, body: JSON.stringify({ title: 'Hello World', content: 'This is a test', }), method: 'POST', }) ```

Free on VS Code marketplace. Feedback welcome!

https://marketplace.visualstudio.com/items?itemName=rxliuli....

Demo Video: https://www.youtube.com/watch?v=9SMLOwZwnU0

I built a simple tool to clean them up instantly. It auto-parses URL params, nested JSON, and formats the body perfectly.

I want to be able to understand your point. For those who enjoy programming, writing code is indeed a pleasure. I spent the whole day today writing a JavaScript serialization package, and even though I know someone has already done it, I am still willing to write a new one for my specific scenario. On the other hand, I think that although AI seems friendly to newcomers (inexperienced developers), it is actually more friendly to experienced developers because you can have AI help you complete some tasks and then review them yourself. Inexperienced developers have difficulty accurately pinpointing problems when they encounter issues, causing AI to keep going in circles and hitting walls.

Based on devalue, I wrote a new JS serialization library called devaluex, which supports asynchronous serialization and plugins. Through plugins, it supports types like Blob, Stream, Error, Request, Response, etc. It is still quite rudimentary at the moment and is mainly used for communication serialization between browser extension Content Script and Background, as JSON.stringify does not support many types. I previously tried seroval (the SolidJS base library) and devalue (the Svelte base library). The authors support more features and use eval (very cleverly) for deserialization. Unfortunately, eval cannot be used in some environments (such as browser extensions). Although the authors also support a JSON mode, its performance is not as good as devalue, so I ultimately chose to wrap devalue.

I haven't used Starlight, but Docusaurus is very slow. The last time I used it, its performance on a large documentation site was terrible, even causing the GitHub Actions Runner to time out. In other words, a single build took over 30 minutes. I never considered using it again after that.

Your journey of discovery is really cool.

I was frustrated with the default styles of @tailwindcss/typography, so I created a plugin that ports GitHub's beautiful Markdown styling to Tailwind CSS.

The plugin (`tailwindcss-github-markdown`) lets you add GitHub's Markdown rendering to your projects with minimal effort - just import it and add the `prose` class to your container, exactly like you would with the official typography plugin. It fully supports both light and dark themes via the standard `prose-invert` class.

GitHub: https://github.com/rxliuli/tailwindcss-github-markdown

As the title says, today I tried using deepwiki to generate links for one of my small tools. The architecture diagrams/flowcharts look particularly good, and the documentation also appears neat and well-organized. I wonder if placing this link on the GitHub repository homepage would be helpful for people using this project, or do you think that content generated by such LLMs cannot guarantee accuracy and only causes confusion?

It looks interesting, I will see what effect it has.

Sorry for seeing the reply so late. This is an interesting idea, and my inspiration comes from Shizuku on Android, which allows granting permission only once using adb commands, and then other apps can use advanced Android APIs through this app without each app having to handle it via command line each time. https://shizuku.rikka.app/

So I think it's possible for Web Apps to have a similar experience. Currently, the Chrome WebStore version has been approved, and Firefox/Safari are under review. Hopefully, this extension can eventually be used in all major browsers (including mobile support for plugins like Kiwi/Edge/Safari).

I was inspired by this Reddit post: https://www.reddit.com/r/FirefoxAddons/comments/1jvg5eu/is_t...

While trying to help solve this problem, I discovered that existing online tools all had various limitations. The top 5 ranked websites either had file size restrictions, couldn't preserve folder structures, or had difficult interfaces.

This prompted me to create myunzip, which can:

- Compress/decompress ZIP files of any size - Fully preserve directory structures - Provide an intuitive user interface - Process everything in-browser with no file uploads

The tool is completely free to use with no ads.

Feedback or bug reports welcome!

Youtube Demo: https://www.youtube.com/watch?v=8F_n_qC5IYc

Very interesting knowledge, I had never really looked into it before.

Hey everyone! I'd like to share CORS Unblock, a Chrome extension that lets web applications make cross-origin requests directly - just like native apps do.

*Why This Matters:* - No need for a backend proxy server - No server costs - No complex CORS configurations - Your web app can directly access APIs like a native app would

*How It Works:* 1. Install the extension from the [Chrome Web Store](https://chromewebstore.google.com/detail/odkadbffomicljkjfep...) 2. When your web app needs to access external APIs, it will request permission 3. You approve which domains the app can access 4. That's it! The app can now make cross-origin requests

*Security & Privacy:* - You control which websites can access which domains - All operations happen locally in your browser - No data collection - Permissions can be revoked anytime

Check out a demo here: https://web-content-extractor.rxliuli.com/

Let me know if you have any questions!

I don't know, is this normal for iOS?

Yes, that's exactly my point. Vue 3 just improves things using existing technologies instead of creating truly fresh solutions.

> I also agree the community is frustrating to deal with a not insignificant amount of time. There are lots of good people, mind you, but also lots of "you are holding it wrong", etc. I reported what is a blazingly clear bug (once you know it exists):

Yes, when I posted this content on Reddit, someone immediately brought up "Svelte's reactivity doesn't exist at runtime" to refute me, which isn't even a valid argument in Svelte 5. https://www.reddit.com/r/sveltejs/comments/1j6ayaf/comment/m...

> put your arguments in order of strength, and remove the weakest ones. Quality wins over volume, and most people are not going to read the whole thing

I did remove some of them, such as the issue of "data ownership," which is the first time I've heard this term outside of Rust's web framework, but it was just a warning, not a blocking issue, so I deleted it. https://svelte.dev/docs/svelte/runtime-warnings#Client-warni...

> In any case, i think some of this is reasonable. But having spent lots of time with frameworks, i'll keep using Svelte5, but I do hope things improve. I feel like i'd spend the same amount of time with other idiosyncrasies if i moved to Solid.

Yes, the current project has been underway for 3 months, and I won't replace the entire web framework now, but I will definitely consider whether there are better options for the next project.

> This is like complaining that types only work in .ts files

It reminds me that React hooks must start with "use," which is a very strange thing, no matter how they explain it. Additionally, I mention this because Vue 3/SolidJS, which also uses proxies, does not require you to use special file names; you can use it in any regular JS.

> This is on purpose, as you know. They want reactivity to be explicit. The benefit of runes is, that if you like Vue and Solid so much, you can literally create their reactive primitives in Runes, and it works.

It just adds extra boilerplate work. Unless you use a custom Proxy to wrap the runes state, I don't think it's possible to implement the Vue Composition API, and if you do that, there will be a double proxy, and even $state.snapshot won't save me.

> This entire section is weird. The title complains about classes, but then the second code snippet is a function back again. And the third is also equally weird, why would you ever need that.

Because the escape hatch left by svelte5 is very strange and seems inconsistent, in the four situations I listed, svelte5 can only make half of them effective, while vue3 and similar frameworks can make them all work properly.

> Same here, Svelte always had this behavior. As you also state, this is present in other frameworks, such as Vue itself, which you're promoting as better than Svelte

Yes, it has always existed, but svelte5 still hasn't addressed it. Also, I don't think vue3 is better than svelte4 because I believe their APIs are very different and not easy to compare. The runes API of svelte5 looks very familiar, and I will certainly try to compare them.

I think Vue 3 is better than Svelte 5's runes, but unfortunately, in my 7 years of using Vue, I've realized that Vue is just a follower of React and may never catch up, as it is only trying to optimize the status quo rather than break the deadlock.

> Yes, but then you can just use a class.

Yes, but I immediately pointed out the oddities of the combination of class and runes below, which looks very strange and inconsistent.

> Despite all this, Svelte 5 introduces $writable

I don't know what this is.

Yes, what I want might be some better React, like JSX, but I don't like the complexity introduced by hooks and the binding of Next.js.