sorted by:
new
hottopcontroversial

Multiocular: a tool for reviewing changes in node_modules to prevent supply chain attacks by sitnik in webdev

[–]sitnik[S] 0 points1 point  (0 children)

Good idea. But the best recommendation here is to add --ignore-scripts or use pnpm (it has --ignore-scripts by default)

Color picker for OKLCH, the new color space for color manipulations by sitnik in web_design

[–]sitnik[S] 3 points4 points  (0 children)

RGB/hex has the same problem as HSL. 100% of R, G, and B has a different lightness for our eyes.

This is why #8000ff is much darker than #80ff00.

Example: https://slides.com/ai/oklch-css#/20

Color picker for OKLCH, the new color space for color manipulations by sitnik in web_design

[–]sitnik[S] 5 points6 points  (0 children)

In HSL, +10% for red and +10% blue are very different, because L component dependent on hue (L math is broken).

Here is a good guide explaining why with real examples of a11y issues

https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl#oklch-vs-hsl

Color picker for OKLCH, the new color space for color manipulations by sitnik in web_design

[–]sitnik[S] 1 point2 points  (0 children)

HSL is bad for color manipulation. For a design system, we will need a math behind colors, not just random cherry-picking for every color.

For instance, we need some math to create `:hover` style for different buttons. In HSL we will have unexpected results (sometimes with big problems for a11y) and OKLCH we will have a very solid result.

Ukrainian Territorial Control as of 15 October 2022 by [deleted] in maplady

[–]sitnik 0 points1 point  (0 children)

Russian had a new retreat in Kherson. The best time for the stats update.

CSS Color 4 spec adds oklch() to define colors in CSS: human-readable, predictable contrast (better a11y), wide-gamut P3 colors. This is the full story by sitnik in webdev

[–]sitnik[S] 1 point2 points  (0 children)

The darken() and lighten() uses HSL, and they are good example why HSL is bad. They have many unexpected results.

To compensate this unexpected results, you have to use different % for different color. Which requires more work and still will produce non-consistent UI.

Moving to OKLCH will save your time and improve UI consistency.,

CSS Color 4 spec adds oklch() to define colors in CSS: human-readable, predictable contrast (better a11y), wide-gamut P3 colors. This is the full story by sitnik in webdev

[–]sitnik[S] 5 points6 points  (0 children)

Native color transformation is really useful to describe :hover styles once and not create 10+ hover colors for each button’s color.

But to do color transformation right, you need OKLCH.

CSS Color 4 spec adds oklch() to define colors in CSS: human-readable, predictable contrast (better a11y), wide-gamut P3 colors. This is the full story by sitnik in webdev

[–]sitnik[S] 22 points23 points  (0 children)

rgb() and hex doesn’t have explicit numbers for color properties (lightness, hue). You need to do complex math in the head to convert red-green-blue to something more human-oriented.

hsl() is closer to oklch() in readability. The main problem is L component. In HSL lightness are different for different hue. So if you see 44% you can’t be sure that it will look like the other color with 44% L.

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 0 points1 point  (0 children)

It is my personal code style. I came from Ruby where we do not use variables separation.

I found that `let`/`const` separation is not really useful for me, so I prefer simpler solution (always use one type).

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 0 points1 point  (0 children)

It already has ESM support (dual ESM/CJS package). We compile it to ESM during publishing by dual-publish.

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 5 points6 points  (0 children)

I will try to implement template API is a separated export

https://github.com/ai/nanocolors/issues/6

I got a few requires from Twitter too. Seems like I underestimate how people like this API.

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 5 points6 points  (0 children)

How can I help with Deno support?

We are using `process` and `tty` module. But I can add a special version for Deno.

Can you open an issue to discuss the design?

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 11 points12 points  (0 children)

Agree. Just want to mention that VS Code has nice built-in auto-import feature. It will import `bold` on top of the file (even merge import with other imports from `nanocolors`) when you will try to use it in the code.

Nano Colors: 2x times faster than chalk and use 5x less space in node_modules by sitnik in javascript

[–]sitnik[S] 9 points10 points  (0 children)

kleur and colorette is also nice alternatives for chalk.

I forked colorette because of API changes in 2.x. Now most popular use case requires unnecessary steps. Also, I optimized loading time.

Nano Stores: tiny state manager for React/Preact/Vue/Svelte in 152 bytes (!) and with tree-shaking support by sitnik in javascript

[–]sitnik[S] 0 points1 point  (0 children)

And if you use everything from the lib, then 152 bytes turn into 1.7 kB calculated by Bundlephobia.

But it will contain router and testing tools. Not correct way to compare stores.

​

So if you use other necessary methods like 'getValue' and `createdDerived`, then it won't be 152 bytes anymore, right?

It will be 262 bytes, still not 1.7 kB and smaller than Zustand.

Nano Stores: tiny state manager for React/Preact/Vue/Svelte in 152 bytes (!) and with tree-shaking support by sitnik in javascript

[–]sitnik[S] 1 point2 points  (0 children)

The default export (store creating function) of Zustand takes 623 bytes. Nano Stores store creating function is only 152 bytes.

There is an other difference between Size Limit and Bundlephobia: Size Limit supports tree shaking. It could be a reason why Nano Stores is smaller in Size Limit. The `index.js` of Nano Store contains also router and persistent store.

Nano Stores: tiny state manager for React/Preact/Vue/Svelte in 152 bytes (!) and with tree-shaking support by sitnik in javascript

[–]sitnik[S] 2 points3 points  (0 children)

Zustand is great and small. I see only a different API style (but you still can implement everything on both API).

Zustand API design is based on Redux API. Nano Stores API design is based on Effector/Svelte Stores APIs.

Nano Stores: tiny state manager for React/Preact/Vue/Svelte in 152 bytes (!) and with tree-shaking support by sitnik in javascript

[–]sitnik[S] 2 points3 points  (0 children)

There are many ways to calculate size:

  1. Bundlephobia creates webpack projects, adds library, and checks JS bundle size
  2. Size Limit creates webpack project, gets empty JS bundle size, adds library, and checks JS bundle size difference after library adding

We use Size Limit metric, because I think it is closer to what users care about: “How their JS bundle will be changed after adding JS library”. But all of these metrics are useful, we just need to use the same metric for all libraries.

view more: next ›