When views are low the math doesn't make sense but it is very possible to get a lot of views through AI generated + human reviewed content.
We're trying to do that with PulsePost (https://pulsepost.io) and the biggest challenge is unique content. Given a keyword or a niche topic, AI models tend to generate similar content within similar subjects. Changing the temperature helps to a degree but the biggest difference comes from adding internet access. Even with same prompt, if the model can access the internet, it can find unique ideas within the same topic and with human review it becomes a high value article.
Yes, the main idea is to clone existing components and to modify them for your own website (use-case) design. You can also create from scratch using the Studio. In both cases you can save and host the components in the cloud.
It has most of the things you said: Create your own component library, easily share through cloud, import and use them, live view and edit them online at Studio [1]
I'm also working on adding versioning and a NPM package so you can refer to your components with unique IDs and directly use them in your code.
Nice! I'm also building an online IDE [1] and was working on adding Chat feature for a while. The problem of making adjustments to an existing component is much more difficult than generating a new one from scratch.
Also, the tokenization for raw HTML code produces too many tokens which drives up the cost. Optimizing the tokenization process for HTML could potentially reduce costs and enhance performance.
I'm currently working on an extension as well ([0]) and share the same concerns many have mentioned about extensions here. I'd like to highlight another dimension concerning the Browser APIs ([1]).
Handling the permissions necessary for certain API functionalities and the corresponding warning messages can be somewhat confusing. For instance, our extension uses "chrome.devtools.panels" to open a new window within DevTools. This API doesn't require any permissions by itself. Yet, for messaging across the popup, content, and DevTools windows, we're required to use activeTab and sendMessage APIs. The DevTools window operates in its unique context, almost like a tab within another tab. For example, updating the URL in the active tab doesn't directly update the DevTools window but triggers an event.
Messaging across these different contexts requires the "https://*/*" host permission, without which Chrome and Firefox won't send the messages between these isolated windows.
We made this permission optional, the DevTools Panel is activated only upon receiving explicit user consent. However, the permission prompt's messaging is something like "This extension requires access to all your data," which sounds very alarming. We don't access any data nor that we want to, but requiring that permission is mandatory since the message APIs won't work without them.
This is just one example of the many undocumented complexities within Chrome's documentation. Similar pitfalls exist with message exchanges between the background service and content scripts. Sometimes you don't know why your API call doesn't work even though you think you have the required permission and asking for more permissions show very alarming messages to users.
I think that a more granular permission approach, made specific to API functionalities rather than broad permissions that cover a list of APIs, would significantly help user experience. For example, requesting permission for the "sendMessage API" with a clear explanation would be far more informative for users than the general "All host https:///" permissions.
There's also the issue of building for different browser. The same browser API calls can have different permissions requirement on Chrome and Firefox which makes the development process more difficult and more confusing for users since the same extension requires different permissions on different browsers.