search

ricokahler / hacker-ui

A design system for the modern developer. (development on hiatus)
https://hacker-ui.com/
MIT License
238 stars 10 forks source link

[ON HIATUS] 1.0 Roadmap #6

Open ricokahler opened 4 years ago

ricokahler commented 4 years ago

Update: 4/13/2020:

Most of the work on this project has been focused on getting the styling system right. This rabbit-holed into creating yet another CSS-in-JS framework. I'm very excited about the direction of the project!

The project aims to support statically extracted CSS-in-JS (similar to linaria) for smaller bundles and better TTI. However, I never fully realized how challenging that project would be (for context, it involves multiple packages and writing several babel plugins to extract the CSS from the JS statically).

As a result of working on that project, original estimates of this project have been delayed until that project is stable enough to use.

Check back soon and check out react-style-system

Update: 5/7/2020:

I've released the first (pre-1.0) version of react-style-system! There's still a good amount of things to be done in that lib but it's good enough to continue more heavy development in this lib. In the next few weeks, expect a v0.2.0 release with more features and a refined vision.

Update: 5/25/2020:

Here is a prioritized roadmap/todo list for v0.2:

Hey all 👋,

Yesterday (2/14/2020), I posted the first release of Hacker UI! I'm really happy with the amount of feedback and interest in this project so let's get to work together and make this thing stable.

Here is a tentative list of all the features and work items I think are necessary to get to a stable 1.0. This list will probably grow and change but at the very least it'll give you a good idea of what's to come.

By virtue, Hacker UI is meant to be a lean component library/UI framework so I think a realistic estimate for all of this is anywhere from 2-3 months given my bandwidth and given a little breathing room for testing and real world usage.

In the next few days, I'll convert some of these bullet point items into issues and I'll mark many of them as "help wanted" with assigned priorities.

If you want to contribute, please check back soon!

Roadmap

Components

Features/Improvements

Docs

Needs Vetting/Auditing

Maintenance/Code Quality

pearlzhuzeng commented 4 years ago

Hey @ricokahler, I really like the premise of Hacker-UI, a simple design system that's decoupled from company branding. I wonder if you can explain a bit deeper your vision for Hacker-UI and other distinguishers of it from other design systems/design systems building tools? I've been reading about design systems lately and specially curious about the following aspects:

  1. What are the design guidelines that these components follow? For example, is accessibility taken into consideration? And if I were to contribute to making some components, what measures should I take for determining what styles to apply? And would tablet interaction be taken into the responsiveness consideration in addition to browser sizes?
  2. Would there be theming capability? I like that you're using system fonts and striving for a simple look, but I find it helpful if as a user of this library, I can easily tweak the styles to make them more aligned with the look and feel I want for certain apps. For example, styled-system is a tool that accomplishes this goal. Curious if supporting theming is on the roadmap for Hacker-UI.
  3. Possibility of using individual components instead of the whole library? For example, bit is trying to do it by allowing every component to be individually installable, and that users can update the components from other repos. Wonder what your thoughts are for making hacker-ui components individually installable and easily extendable.

I find this project very cool and has tons of potentials, amazing work! Looking forward to what comes next!

ricokahler commented 4 years ago

Hey @ricokahler, I really like the premise of Hacker-UI, a simple design system that's decoupled from company branding. I wonder if you can explain a bit deeper your vision for Hacker-UI and other distinguishers of it from other design systems/design systems building tools?

Thank ya! I'm really excited about this project and from initial postings I did, it seems like a decent amount of other people are excited too. Thanks for asking all of these great questions! I've been meaning to write something like this so this is a great push!

1. What are the design guidelines that these components follow?

I have some docs on this on the current site, but I think they could use a bit of improvement.

The three biggest "design guidelines" I want to highlight is:

These three principles are arguably more relevant to the implementation rather than how to design with it but I think it also shapes the overall philosophy of Hacker UI enough to reason whether or not a design complies with this system.

They're relatively broad principles 😅 but I think they can take us far. For example, if you look at certain interface and it looks too cluttered or is unclear what's going on, then it's not simple. If there exists too many variants of certain component then it's arguably not lean, and if components don't share the same behavior in different contexts then they weren't built with reusable atoms composed together.

Also: I see the brand of Hacker UI adopting the brand of "hackers" in general. A quick go-to example is Hacker News. All of us check that dang site regularly simply because:

  1. it's simple,
  2. it works, and
  3. it's stable.

That's what I want for Hacker UI — it should just work and remain stable. In order to do this, it needs to be a simple design system that doesn't create too many abstractions. By this, I mean that it should embrace using the browser and the layout tools it provides (e.g. flex, grid, @media) over creating deep abstractions over those.

Hacker UI should be also be hackable and ready for rapid prototyping. Because the philosophy is to stay lean, the learning curve is low thus making it more hackable.

For example, is accessibility taken into consideration?

Yes 100%. Since Hacker UI's philosophy is to stay lean and leverage what the browser provides, it's much easier to make components accessible (because they're already accessible or made-to-be-accessible in the browser by default). More or less this boils down to using HTML elements and forwarding all props and refs to those components.

And if I were to contribute to making some components, what measures should I take for determining what styles to apply?

Keep it simple. Don't create deep abstractions over the browser. Make it look good but without introducing too much bloat. 😎

And would tablet interaction be taken into the responsiveness consideration in addition to browser sizes?

By the nature of Lean/Composable, most of the components in Hacker UI shouldn't even have to worry about browser sizes (e.g. an atomic Button component doesn't need a media query), however the components Hacker UI ships should be atomic enough to work in the context of both mobile and desktop.

2. Would there be theming capability?

Yes! there actually is theming capability already built-in in the current released alpha.

I'm concurrently working on another project react-style-system that is a separates out Hacker UI's CSS-in-JS lib. This CSS-in-JS lib follows all the same principles of Hacker UI (e.g. Lean, embrace CSS + HTML, low learning curve, etc).

Here a sandbox where I changed some fonts to Times

There's some new ideas in this CSS-in-JS lib that I think solves a lot of problems in regard to theming. In particular, the color system in this lib solves a lot issues that I can explain in another post if you're interested.

3. Possibility of using individual components instead of the whole library?

I currently have no plans on publishing each component separately, even if facilitated by bit.

And my reasoning for why is: With this system's philosophy of "lean", this lib should not get large enough to the point where bit significantly helps. Also: Hacker UI already supports tree-shaking so in theory, if you don't import the module, your final bundle should not include it.

For size reference, Hacker UI in its alpha state with all its components is 18kB gzipped.

Material-UI's button component is 24kB when imported separately according to bundlephobia.

image

I also have a lot of bundle size optimizations coming up that should take it to the next level for Hacker UI. In particular, I'm currently writing a babel plugin that extracts out the CSS you write with Hacker UI out of the JS.

image

This means that the final bundle for Hacker UI will only contain JS needed to inject the extracted style sheets with CSS variable values.

This CSS-in-JS solution is basically a combo of Material UI's styling solution and Linaria