Migrate from glimmer.js to svelte

[chadian]

This pull request migrates Vorfreude from glimmer.js to svelte (and addresses #6). Jumping from where glimmer.js was back when this project started to where it is now was too big of a leap to the point where it felt similar to a rewrite. The glimmer.js project doesn't feel as stable now, I ran into contradictory documentation and it looks like a few of the conventions are in flight as rfcs are changing. Considering this, along with the fact that Svelte is more stable and offered a new opportunity to learn, I decided to go ahead with Svelte.

It'll be interesting to compare what sort of bugs crop up from the migration as well as any benefits like performance or overall bundle size.

• Remove glimmer.js implementation
• Update README
• Write acceptance tests
• Finish migration with tests
• Try object-fit with object-position and flex box instead of fixed/absolute and background-image (check for resize performance, too)
• Manually test extension build steps in the chrome folder
• Test routing works for settings from extension options
• Verify other manifest.json relative build artifacts (ie: icons, etc) are loaded correctly
• Add testing around the fetcher, manually test, and possible design differently

---

Takeaways from the migration

While glimmer.js has stagnated, it's bigger sibling Ember.js has a lot of out of the box that was lacking in Svelte(Kit), although Svelte(Kit) also had a few things that Ember could learn from.

• (Routing) Ember's router is much more mature. SvelteKit's file-based routing borrows a lot of conventions from Ember and in some cases has some nice hooks that are easy to use but not being able to easily support hash-based routing and pushing a number of SSR and prerender techniques and configuration made it a bit confusing. Essentially, Sveltekit expects to be hosted in a way that can handle this from something like Netlify and the single-SPA mode was a bit awkward.
• (Components) Svelte wins here in many ways. The way reactivity works with stores seems to be more obvious with how reactivity is handled. It's easier than useState in react, and a little more explicit that tracked with Ember since $ and the store interface feels more like "just javascript", ie: being able to use the subscribe method to subscribe to changes is nice and when used in templates $store is syntax sugar to tracking those changes in the DOM. Also the arbitrary javascript of react combined with similar template helpers of ember makes svelte work really well ({#if}{else} in svelte vs {{#if}} in ember vs weird ternary or condition && result in react). Defining a component interface via ES Module exports feels odd, like it betrays the semantics of modules and expectations around export 🤷.
• (Testing) Ember wins here. Having to use testing-library with svelte and jest/js-dom along with SvelteKit's playwright left a lot to be desired. Playwright is nice in that it's "more real" in simulated browser interactions but ember's abstractions around haven't failed me yet. Playwright is great, but having to have different setups, jest/jsdom and playwright, for unit/component and acceptance test, respectively, it a bit more work and requires an understanding of different APIs and mental models of how the environment they're running in. With ember, you're always running in the browser, you're always using the test'em runner, and the apis are consistent across both. Overall though, the Svelte testing is much quicker.
• (Build) This goes back to the (Routing) point but Ember is more versatile in how it builds. Maybe vite with Sveltekit has better chunking/tree-shaking support but the final artifacts for SvelteKit are so geared towards the SSR/prerender use cases that it seemed less flexible to the "just html, css and js" use cases. Also my SvelteKit build for the chrome extension required some hackery in the build to get SHA's around the artifacts as to satisfy content security policy (CSP) restrictions for browser extensions. This was due to the fact that to kick off the app SvelteKit uses inline javascript in the html and ember bundles this externally. While in "dev mode" the vite builds with SvelteKit were lightning quick and didn't require refreshing the page with hot module reloading "just working", that felt like magic.

All in all Svelte and SvelteKit look very promising. Much of it feels quick to pick up and the APIs seem barebones enough that you only reach for what you need and when you do the learning curve is incremental in a way that mostly works and feels natural. Some of the infrastructure and ecosystem around Svelte and SvelteKit seem like they still need more work but it does seem like it's setup in a way that it can be extensible and improve (ie: there was an extension adapter for building browser extensions but it failed out of the box with an unresolved issue that was listed on the GitHub).

There are other areas where Svelte should shine even more, like animations, but I didn't have a reason to explore these. After working around build and routing issues SvelteKit does feel like a good choice and hopefully provides a bit more opportunity for this little app to grow even more.