Echo JS 0.11.0

Cool, although I do wish there was some indication of the payload size/overhead for this.

The biggest issue I've had in embedded editors like this, is the payload is often pretty massive... I usually like to defer as much as possible to only screens where needed/used.

Adjacent is the need to sanitize html pasted content (such as from MS Word).  It's the bane of all human existence.

Seems to be a simple abstraction, since D3 is a very flexible API, it can be easier to work with simpler components.  I haven't looked into this, so can't recommend or comment, just replying on why one might want to use this, or something similar.

A lot of charting/graphing components use D3 under the covers.

With the exception of a few server and app module environments (such as adobe extensions), since nearly every browser is auto-updating, I tend not to support anything more than a year old for browsers... Phones are a little niggly, but even Android has separated chrome updates from android.. and Apple does updates for even fairly old devices.

For me, I use ES2020 features without much fear.  Just my own $.02 at this point.  Anyone that would disable updates is a security risk, and I'm fine with them not being able to use the applications I work on at this point.

Definitely a nice to see feature... should probably enable by default for repositories with a package.json, like the package security/staleness checks.

Maybe my biggest niggle is that the styles' structure is in a mirrored tree instead of relevant CSS in/beside the component being styled.  Beyond this, the first instruction includes a css-in-js library, and mui contains another still.

This also covers way too much for a single article.  Realistically this could be several articles each covering a smaller piece and actually explaining the walls of code adding them a bit at a time.

Appreciate the inclusion of a plain JS example at the bottom.  Thankfully most browsers are green, continuously updated now, so the relatively new feature is available in anything current.

https://caniuse.com/?search=fromEntries

TLDR Url: https://github.com/mocks-server/main/tree/master/packages/config

Would be useful if you're writing configurable modules that will be used by other projects.

Aside: Wouldn't use this for applications/services as I tend to prefer environment variables, and load ~/.env with find-up directory tree searching from cwd.  .env for local use, defaults for local dev and environment injection on deployed servers.

Surprised this isn't using shadow dom for display, but cool all the same.

Many of these are arguable as the hinting system from typescript in modern editors (vs code, jetbrains, etc.) are able to determine return types, just as an example.  Of course this can be argued of linting generally speaking, so it's okay as options.

My biggest niggle with TS lately, is that tsc and deno have different import rules... for deno, you must use the extension, for tsc you must not, and I really wish tsc could be changed via an option to match the deno behavior, which I feel is more correct.  I think being able to share modules between the node/esbuild ecosystem and deno is going to become ever more important in the next couple years... especially if you can just share the ts source directly instead of built js modules with separate definitions.

Personally, I tend to prefer a feature oriented structure... where each feature is where directories are separated, and subdirectories created as necessary.

Each feature containing it's own context/state, components, tests and data fetching...  this can be registered with core routing and used in concert with more generalized components/wrappers.  It also tends to make it easier to break down into more of a micro-ui pattern if needed.

You can use redux-micro-frontend for state management in concert with exposing React and your UI component library of choice as global patterns from the start.  Again, easier to break things up later.

Just my own $.02