Echo JS 0.11.0

11 paragraphs, sections, blurbs and bullet points before the ad block, and no content/example or demonstration of why it is a better workflow.

Comparisons to real DOM vs vDOM are somewhat immaterial from the developer experience... and iirc, React are considering removing virtual DOM since the browsers have improved since React first started... it doesn't change the flow.

React's size is an issue... and tbh, not sure why it's still as big as it is.  I get it during dev, they add a lot, and it's possible what's left is mostly cruft for dev experience... unsure.

The comparisons at the bottom are slightly more interesting... I'm frankly surprised that SOLID didn't just follow the React API for a lot of the hooks/naming, it makes it more different, but also makes conversion a hindrance.  The foo-compat libraries (such as preact-compat) are what make them better suited for a quick swap.

The biggest thing for any upstart react-alike or JSX framework or library to overcome is going to be React's entrenchment and ecosystem.  There are a *LOT* of modules, UI, state, and other libraries that work with React... anything that wants to unseat it and be similar, needs to be mostly compatible, that is just my own take on this.

In the end, I generally hate comparison articles, at least this one focuses on only comparing two, and apparently part of a series.

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.