I rarely see good javascript/webdev/typescript related blog articles here, which is what I'm actually in here for.
I'm not interested at all in release notes for example. Especially not minor or patch versions. I check out GitHub or the product website for that regularly. Although for some things like nodejs it's not that transparent. A separate website/service for release notes that collectively gathers summaries of updates and to promote new packages would be welcome to separate from the learning material. Part of development is also to hunt for good packages and components. Being able to see them in one place rather than scattered here would be better I believe.
I agree with you that Blockchain/Bitcoin does not belong here. When it comes to AI, the lines between programming and ai are blurry. I'm not interested in posts that try to sell their services to me, whereas news about js-related services such as Deno Deploy with generous free tier are welcome to me.
I primarily use Echo JS to learn new techniques, methods, ways of doing something. These are sadly the minority of posts.
TypeScript is becoming more and more ubiquitous and I think that is a good thing. 4 years ago, I argued that valid JS is not valid TS, but TS has matured a lot since then.
I would also go as far, to teach new programmers TypeScript from the start, rather than JavaScript.
JavaScript involves a lot of guesswork or try and error if you know nothing.
How do you explain to someone that some DOM event _will_ have a special property they should consume? REPL-based programming is still a thing for trying out that kind of things and it helps greatly to learn about the return values (or types) of functions. But once you know what an event listener is, what you can attach it to, you really want to rely on signatures right off your editor. Code is documentation too, and TypeScript enables code to be self-documenting in a way. If implemented correctly, I don't have to try out functions but simply know what they do by looking at their signature, which means a great productivity boost to me.
We still have a large gap between the developers that sprinkle in JavaScript as additive for some special effects on regular websites or full-blown web apps that have devops baked into them. Think PHP in ~2010. There are still people using FTP to deploy their websites, so an extra build step comes with a huge up-front cost you probably don't want to pay.
In these places, usage of TypeScript is kind of a gray zone, as you cannot rely on completely automatic deployment.
Which is why I am looking forward for the type annotation proposal: https://github.com/tc39/proposal-type-annotations
Good alternative to useState for an array of objects:
useListState - https://mantine.dev/hooks/use-list-state/
I remember mui also had one, but can't find it right now.
Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library.
1. configurable log levels (convention is fine, but some apps require more fine grained control)
2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty)
3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications.
4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter.
**Other things to note:**
your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option)
It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance.
Your methods are repeating the same logic over and over. Put them into a shared function.
Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library. 1. configurable log levels (convention is fine, but some apps require more fine grained control) 2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty) 3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications. 4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter. **Other things to note:** your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option) It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance. Your methods are repeating the same logic over and over. Put them into a shared function.