[HN Gopher] Show HN: Plasmo - a framework for building modern Ch...
___________________________________________________________________
Show HN: Plasmo - a framework for building modern Chrome extensions
Hey HN, we're excited to have people try out our framework! When we
built out a Chrome extension earlier this year, we noticed that the
config was too imperative. You had to constantly tell Chrome via
the manifest.json file where your files were, what your permissions
should be, etc. So we thought it might be interesting to build a
more declarative framework. When we built a proof of concept, we
enjoyed working with it and decided to invest more time into making
it usable and adding more features. We're still pretty early in
building it out, and there's a bunch more we want to add, but this
feels like a good time to showcase it and hear what people think!
Author : coldsauce
Score : 39 points
Date : 2022-06-03 15:46 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cxr wrote:
| > System Requirements
|
| > Node.js 16.x or later
|
| Plasmo's "users" will already be working under the constraint of
| developing for a target platform where NodeJS will not be
| available to them, but is nonetheless meant for running JS:
| Chrome. Why is NodeJS necessary?
| coldsauce wrote:
| Our tooling is written in Node.js. So developers must have Node
| installed on their machines to utilize our tooling.
|
| When they use our CLI to watch the file system for changes for
| live-reload or to build their extension, etc., that's a Node.js
| program.
|
| The build target is browser Javascript, though.
| cfu28 wrote:
| This is neat. How does live-reloading work? Manually reloading a
| chrome extension with each code change has been a pain point for
| me in the past.
| coldsauce wrote:
| Thanks! We wrote a custom Parcel runtime [1] inspired by
| Parcel's HMR runtime (which was too bloated and buggy for us)
| that injects a web socket listener into the development build
| of the extension.
|
| Whenever a bundle change happens, Parcel sends it the refresh
| message and it either does `chrome.runtime.reload()` or
| `location.reload()` depending on the context.
|
| [1]:
| https://github.com/PlasmoHQ/plasmo/blob/main/packages/parcel...
| silax wrote:
| Love this. Chrome extensions are the most underrated platform to
| spit out 7+ figure recurring revenue businesses on. Mac App Store
| close second. I'm hesitant to even mention because it's such a
| good secret.
| ekabod wrote:
| Can you point to one extension that is making 7 figures?
| Raed667 wrote:
| Looks very promising. I'm wondering about the current state of
| cross-browser compatibility.
|
| How close are we to being able to write MV3 extensions that run
| on Chrome/Firefox/Safari without code adaptations?
| coldsauce wrote:
| There's standardization work being done at the moment with the
| W3C WebExtensions Community Group [1] which is definitely a
| step in the right direction!
|
| Mozilla has also done some great work building a web extension
| polyfill library that attempts to abstract away the differences
| between the browsers [2] but the translation will always be
| imperfect, and edge cases are abundant.
|
| [1]: https://www.w3.org/community/webextensions/
|
| [2]: https://github.com/mozilla/webextension-polyfill
| [deleted]
| FractalHQ wrote:
| I found making Chrome extensions with Sveltekit was very easy
| thanks in part to its use of Vite. Any plans to support anything
| other than React?
| coldsauce wrote:
| It's definitely something we want to consider in the future!
| Right now, we want to focus on a single view framework and make
| the developer experience as seamless as possible with it. The
| framework we've chosen is React because we're most familiar
| with it.
| leodriesch wrote:
| Currently using Parcel with its support for manifest.json as an
| entrypoint[0], could you explain what your framework does beyond
| that?
|
| [0]: https://parceljs.org/recipes/web-extension/
| coldsauce wrote:
| We use Parcel under the hood and are huge fans! Our framework
| has opinionated abstractions on top of it that we think help
| improve the extension development experience considerably.
|
| Features we've built so far:
|
| - manifest.json is generated automatically. If you want to
| create a content script, you name a file content.ts, and it'll
| auto-gen the right manifest key-value pair for it. Same with
| backround.ts. [1]
|
| - Mounting a React component to the popup or options page is
| similar. You create a popup.tsx or options.tsx file, export a
| default React component, and it'll automatically associate it
| in the manifest and mount the component automatically for you.
|
| - We support environment variables with .env files [2]
|
| - We just released support to automatically inject a shadow DOM
| into a webpage and mount a React component from a content
| script [3]
|
| - We have remote code bundling that automatically fetches URL
| based imports (like Google Analytics) in build time to mitigate
| issues with MV3 not allowing remote code [4]
|
| [1]: https://docs.plasmo.com/#where-is-the-manifestjson-file
|
| [2]: https://docs.plasmo.com/workflows/env
|
| [3]:
| https://github.com/PlasmoHQ/examples/tree/57791e70549441e391...
|
| [4]: https://docs.plasmo.com/workflows/remote-code
___________________________________________________________________
(page generated 2022-06-03 23:00 UTC)