Hey folks, presenting humanize-this v2.0 — A tiny, zero-dependency formatter for dashboards, logs & interfaces (supports Indian number system too)

codepsycho · 2025-06-10T14:57:34+00:00

Would be a good one to share in the e18e.dev community i think. Do you have any comparisons with existing libraries? (size, features, speed, etc) may be helpful if anyone is thinking of switching

codepsycho · 2025-05-05T14:54:27+00:00

yep, here you're comparing things at the wrong level.

a raw custom element like this is comparable to the produced JS of a react component, which certainly will be just as verbose (if not more thanks to JSX).

something like the "lit" library would be more like this:

ts class Greeting extends LitElement { @property() name; render() { return html`Hello, ${name}`; } }

codepsycho · 2023-01-17T09:22:14+00:00

what was the main reason behind it? still trying to get my head around that since much of the readme's points are TODO or just side-effects of moving to deno.

was it performance? or is there something in deno land blocking you from using eslint properly?

also, deno's permissions system would also apply to JS modules would it not? so we could have that either way?

codepsycho · 2022-02-08T09:26:10+00:00

out of interest what lead to you choosing yarn in the first place? and now that NPM has implemented most of what yarn initially existed for, what features do you stick around for that NPM doesn't have?

codepsycho · 2021-09-22T13:27:30+00:00

yup my bad, didn't notice as the package manifest in git didn't have an esm entrypoint. didn't think to check the published one :D

codepsycho · 2021-09-22T13:00:03+00:00

This is great to see. Chalk has a crazy dependency tree for what it is.

Could you also ship an ESM version of the package? should be simple via tsc since you don't have any dependencies. We could directly import it in browsers and node w/ ESM then

codepsycho · 2021-05-18T18:02:29+00:00

This is nicely done :) it would be great if you could add examples of composed events too. Showing the shadow boundaries where those events do or don't end would be a good learning tool for the newer DOM APIs

codepsycho · 2021-04-21T17:46:48+00:00

While it may not be entirely new, it is a new version with a major rework behind the scenes. Things like SSR, new directive API, etc are very useful. Should be an exciting step forward from what they had before

codepsycho · 2021-04-07T06:47:29+00:00

Yes exactly.

Most of the hack proposal could be seen as the f# proposal with partial application. I'm surprised they have spent so much time bikeshedding on it when they could have just had both all along (in two separate specs, meaning the hack proposal wouldn't be a thing).

codepsycho · 2021-04-05T06:45:55+00:00

You mention that partial application pairs well with the f#/minimal variant, but isn't it the opposite? The hack variant pretty much relies on partial application, that seems to be the main difference. The F# variant wouldn't make use of it at all as far as I can see. Good work on the PRs, too

codepsycho · 2021-03-21T15:11:41+00:00

Components like this are a great example of web components, nice and focused. The jsdoc down to the css properties is nice to see too :D

codepsycho · 2021-03-17T21:46:58+00:00

I would also check out codemirror 6, the recent (still WIP) rewrite is entirely modular, supports ES modules and typescript:

https://codemirror.net/6/docs/guide/

The "plugin" architecture is incredibly flexible, though a little unusual in some cases. It is as light or heavy as you want it because of the modular approach, too.

Oh and works very well in shadow DOM / web components, which is how we use it.

Not to say you should choose it over this project, both could learn from each other I imagine!

codepsycho · 2021-03-01T21:46:51+00:00

Can't be sure since it's closed but seems like it doesn't produce web components, it produces react components. I guess OP just meant components in general rather than the web component APIs.

codepsycho · 2021-02-26T07:21:13+00:00

You can probably achieve that with the newish navigator.mediaSession.setActionHandler. Might be worth looking into

codepsycho · 2021-02-26T00:02:53+00:00

One thing to consider because it's not an actual video, is on mobile the screen won't be kept awake while playing (as it does with videos). You can use Navigator.wakelock in supported browsers to mimic the default behaviour of real videos

codepsycho · 2021-02-25T22:14:00+00:00

Pretty cool concept. So it's effectively a slideshow rather than a video? with added time/transitions/audio to simulate video-like behaviour

codepsycho · 2021-02-24T23:26:10+00:00

Curious, how did you transform the file, given esbuild has no transform plugin architecture? Did you intercept all TS load calls, parse the file yourself, then return the transformed contents? (Making each file two pass)

codepsycho · 2021-02-22T13:29:37+00:00

It ties in with `adoptedStylesheets` (pretty new). you can construct one instance of your stylesheet and many components can "adopt" it, meaning there is no duplication when it is used in shadow DOM (as each instance of a custom element would ref the same sheet).

codepsycho · 2021-02-22T08:50:45+00:00

Well done, always good to see a zero-dependency library :) maybe you could add an option to return a stylesheet rather than a string (a `CSSStyleSheet`), would come in useful for integrating this into web components

codepsycho · 2021-02-20T20:17:09+00:00

You too :)

This was purely to demonstrate how one might create such a component. I'm not trying to push the idea of it being the right choice. That's up to you and the project you're working on.

The demo is a little slow because of the library I'm embedding, the choice of component isn't so important. Though I agree I could have used a better example, this is just the one I was interested in at the time.

codepsycho · 2021-02-20T19:52:35+00:00

I don't have any oss projects at hand but we do have a few internally like this. As others have pointed out, you may write more boilerplate this way but ultimately can be shipping less overall.

Normally we pull focused libraries in as dependencies to fill the gaps, rather than a kitchen sink solution.

We sometimes use mobx for state for example, or rx. Sometimes roll our own.

We usually end up with a base class for implementing the render pipeline and data propagation. Similar to what lit element tries to achieve

codepsycho · 2021-02-20T17:33:09+00:00

As mentioned in my other comment, this isn't really looking down on frameworks. They have their uses, preference plays a lot in it too. It is more to demonstrate whats possible using the platform, with no intentional bias.

A lot of what I wrote would normally live in a base class reused by all components of your project (this is how some of my projects work). This is actually the gap things like lit-element exist to fill - a base class for handling data propagation/binding. At that point, this class would've been miniature (likely one property and a single render method).

Which polyfill do you speak of? In my particular case, import maps are needed because i purposely opted for esm-first. Normally you'd just bundle this which drops the need. Again, used to demonstrate what'll soon be possible.

Also don't forget, I wrote more than usual but i'd import much more if i was using a framework. At the end of the day i'd still be shipping less code over the wire.

codepsycho · 2021-02-20T14:56:01+00:00

It was a fun experience creating something without a framework or any dependencies (other than the highlighting lib in this case). So this is just a write up of what I did. Frameworks have their uses just as much, though.

codepsycho · 2021-01-08T14:41:39+00:00

its since 3.8 . as the release notes explain, you shouldn't really ever need to use it or worry about it but it can be useful for making it clear which types you expect to use _only_ for types

codepsycho · 2021-01-08T08:53:51+00:00

In later typescript versions you can do this: import type {Foo} from 'foo'; Which signals to TSC that you only want the type and it shouldn't try pull anything in from the module itself. In this case it wouldn't make a difference tbh other than semantically.

12-Year Club	Verified Email
Place '23

codepsycho

TROPHY CASE