[HN Gopher] Show HN: Mirrorful - A developer-first way to implem...
___________________________________________________________________
Show HN: Mirrorful - A developer-first way to implement designs
faster
Hey HN! Mirrorful (https://www.mirrorful.com/) is an open-source
developer framework that helps front-end engineers manage their
design systems. We've been building Mirrorful with the open-source
community (https://github.com/Mirrorful/mirrorful) and wanted to
share our beta with you. Check out our online demo to get the idea:
https://app.mirrorful.com/. Design systems can be thought of as
the "building blocks of your app" which makes me think of Lego
bricks. Mirrorful helps you manage your codebase's Lego bricks and
ensure that they are consistent across all of your apps and
platforms. We saw as product engineers how hard it is to get code
to match Figma mock ups. High-quality design is a competitive
advantage, so getting your UI pixel perfect can matter a lot, but
is time-consuming and tedious. When we worked for large public
companies, we saw that good component libraries help, but engineers
are often still dealing with tweaking small design decisions. There
are a lot of inefficiencies. We also worked at a small startup and
saw what it was like to not have a design system. No design system
led to copy pasta code, and days of back-and-forth on simple things
like "what hex should i be using for the hover state?" Design
systems are tricky to get right. Picking an out-of-the-box solution
is easy to begin with, but one day you'll be cursing yourself due
to lack of flexibility (we did!). On the other hand, creating a
design system from scratch is super time-consuming even for the
best frontend engineers. Mirrorful is our way out of this dilemma.
Mirrorful is completely open-source and written in Typescript.
We're starting with basic design elements--commonly called "design
tokens" -- such as colors, typography, and shadows, but have plans
to expand our scope into more complex components. As frontend
engineers ourselves, we wanted a tool that lives in code but is
visual. It had to be super easy to set up, but also prepare you for
scale so you and/or your team don't end up copy-pasting everywhere.
We decided to make it an NPM package
(https://www.npmjs.com/package/mirrorful) that runs a localhost
editor and exports out your design tokens into any configuration
you want: .js, .ts, .css, .scss, .json. It's lightweight with no
design system lock-in. Our product is completely self-serve: just
install our NPM package. If you run Mirrorful locally, a visual
dashboard will pop up at localhost:5050 that lets you manage your
theme and export various configuration files directly into code.
Pricing is similar to other open-source companies--we charge for
cloud-hosted features and for premium components. We've built
open-source/open-core projects before and love interacting with
contributors from all over the world. If anyone has any opinions on
what we're building, we're all ears. Check us out at mirrorful.com
and at github.com/Mirrorful/mirrorful and give it a shot!
Author : teddarific
Score : 48 points
Date : 2023-03-29 15:19 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| digdugdirk wrote:
| Interesting. Given the "design tokens" aspect, would it be
| possible for a non frontend/non Javascript developer to use this
| to design components that could be imported and used with
| PyScript?
| teddarific wrote:
| I'm personally not super familiar with PyScript, but I would
| bet so! We store the tokens currently as JSON and have a few
| "translator" pipelines that convert our object into consumable
| code. I think we'd just need to add one for PyScript / Python!
|
| Do you have a project you'd be looking to add this to? We're
| happy to take a look!
| jasonwcfan wrote:
| Congrats on the progress! Generative AI is all the hype now and
| there's a few startups exploring using AI to generate front-end
| code. Is this on your roadmap as well?
| teddarific wrote:
| Absolutely! We're definitely excited about generative AI and
| the applications of it to reduce the tedious aspects of
| frontend engineering.
|
| We're actually currently working on a feature to help generate
| color palettes using AI, but have some thoughts around code
| mods (since one of the most painful points of design systems is
| migrations) and generating components.
| Nijikokun wrote:
| Whats the benefit of this over something like docz or storybook?
| Which are also agnostic to framework?
| teddarific wrote:
| We're actually huge fans of platforms like Docz and Storybook!
| With Mirrorful, we want to complement these documentation-first
| platforms rather be a replacement (some of our initial users
| use both us and storybook!).
|
| We're more focused on the actual implementation aspect of
| building new features, rather than serving as a reference. For
| example, Mirrorful helps ensure that an engineer is using the
| right color that the designer intended and isn't just hard-
| coding colors all over the place.
|
| I think our value props are similar, in that we're all looking
| to speed up engineering velocity and help with design
| consistency, but targeting different parts of the workflow.
| There's a lot of places where things go wrong in the process
| today!
| yewenjie wrote:
| Interesting. Two questions
|
| 1. How does this compare/relate to https://backlight.dev/?
|
| 2. How does a designer work with this? Is it meant to be used by
| developers only? Where does this fit in the Figma --> Code
| workflow?
| teddarific wrote:
| 1. In our personal experience, we found Backlight to be a
| little bit heavy. We want to focus heavily on augmenting
| existing processes, rather than change how teams work. There
| definitely is a time and place for Backlight though, we think
| its an awesome product!
|
| 2. We're currently focused on the developer experience, but we
| believe that working with designers is part of the developer
| experience! We like to think of ourselves as the "translation"
| layer between Figma and code. A direct Figma integration is in
| our roadmap ;)
| haolez wrote:
| Looks interesting, but I'm looking into Flutter right now, so I
| guess this is not for me yet.
| joduplessis wrote:
| Nice work! Whilst I do love the hands-on approach of something
| like Style Dictionary, I can see the value prop here. Especially
| with design system standards semi-converging (in the wild at
| least).
|
| Any plans on supporting native platforms in the future (sorry if
| I missed it in the docs)?
| roycebranning wrote:
| +1 for native platforms!
| teddarific wrote:
| Any specific platform you have in mind?
| teddarific wrote:
| Love your point about design system standards semi-converging,
| we totally agree! We think design systems is slowly
| transitioning from an art to a science.
|
| We do have plans on supporting native platforms! We've been
| holding out a little bit to see what folks specifically in
| mind, so if you have a thoughts or a specific platform in mind,
| let us know and we'll get it prioritized!
|
| Also, we have an active Slack community if you're interested in
| conversing more there:
| https://join.slack.com/t/mirrorful/shared_invite/zt-1ps2xtxh...
| anongraddebt wrote:
| I would love native platform support. I'll write up some
| initial thoughts and drop them into the Slack.
| teddarific wrote:
| Would love that! See you in the Slack!
___________________________________________________________________
(page generated 2023-03-29 23:01 UTC)