Sozai

UI framework with vuetify-like material components built with Svelte

Usage

I made the library to be as easy to setup as possible. No preprocessors for css or js are required.

First, we install sozai with npm

npm i sozai

Then, we surround the main component with <SozaiApp />

<!-- App.svelte -->
<script>
  import { SozaiApp } from 'sozai';
</script>

<SozaiApp>
  <!-- Put your app in here! -->
</SozaiApp>

And boom, we've set up a sozai app. No need to mess around with the bundler to correctly setup purgecss or postcss!

Testimonies

-- @KentoNishi (named as one of the top 300 scholars in the 81st Regeneron Science Talent Search—the nation's oldest and most prestigious science and mathematics competition for high school seniors)

-- @anish-lakkapragada (made an ml library when he was 14 although not with sozai)

Motivation

I mainly have worked on LiveTL which upon rewriting in svelte a year ago, has used a svelte material ui framework. Our journey took the following steps.

1. We find svelte-material-ui as the most popular material toolkit for svelte around the time v2 was in beta. I struggled to set it up and after a day of messing with bundler configs, gave up 😢
2. We find svelte-materialify and start to use it as it initially required no setup. It is also, in our opinion, the best-looking svelte material toolkit. However to use the full library, we needed to setup css preprocessors which was annoying but doable.
3. A few months after we successfully rewrite LiveTL using svelte-materialify, we realize that svelte-materialify is buggy af and bugs out on conditional renders and randomly started flickering.
4. A few months later, we plan to integrate with another project which adds the requirement that the bundle size be small for LiveTL. Unfortunately, svelte-materialify does not tree-shake and produces massive bundles.
5. We swap out the svelte-materialify components with smelte and immediately see a drop in bundle size. However, the build time has increased due to needing to use purgecss in order to not end up with megabytes long css files. Months later, one of the other three core LiveTL devs and I are fed up with tailwind (smelte forces you to add tailwind to your app). In addition, smelte seems to be unmaintained.
6. I say fck it, I'm making my own toolkit.

Comparison

Everything has pros and cons, let's compare sozai to the other svelte material design frameworks.

|Framework | Pros | Cons | Verdict | |----------|------|------|---------| | sozai | Developed along with development of https://taskaru.app (will be open sourced soon) so it is tested in production Easy to setup I made it | Slider is buggy on safari ios Can only use material icon font I made it | Use this in small/nonimportant apps | | svelte-material-ui | Actively maintained Sveltekit support Very stable Accessible Supports both mdicons and material icon font Uses the official material design css | IMO doesn't look the absolute best Ripple effect is not very nice May still be hard to setup (haven't tried recent v6 yet) | Use this if you have a serious app. | | smelte | Works well First-class tailwind support | Looks the ugliest of svelte's material framework (although still looks decent) Unmaintained First-class tailwind support | Use this if you enjoy the pain that is tailwind but be prepared to write wrappers around smelte components. | | svelte-materialify | Components look very nice Looks a lot like vuetify | Buggy Unmaintained Doesn't tree-shake | Don't use at all. |

Credits

Sozai's ripple is based off of svelte-materialify's ripple (we changed it to activate on touch events and fixed some bugs with it). Sozai also makes extensive use of svelte-material-ui's event forwarding mechanism which forwards all events dom elements emit. Sozai was initially meant to be smelte without tailwind and due to this, sozai's button and dialog are more or less smelte's but de-tailwinded.