thymanl23

The crux of the article: "The answer is simple, if not exactly satisfying: when enough of the population—possibly 60 or 80 percent of people—is resistant to COVID-19"

But then in the next paragraph nonchalantly says "though we don’t yet know if recovering from the disease confers any immunity at all"

I'm not sure sure how articles like these get published.

Check out "The Problem with Promises in JavaScript" [0] for some gotchas with the design of js promises.

[0] https://dev.to/craigmichaelmartin/the-problem-with-promises-...

Hooks are a reconception of state and effects within a declarative model.

Rather than effects being tied to a component's mutable lifecycle, they are tied to the data.

Rather than state being tied to a mutable instance, it is declaratively passed in.

The issue I found with the raw SQL approach was receiving back flat results. I made PureORM[0] to do only and exactly that: map flat data to correctly nested business objects.

It is called "pure-orm" both because it is _purely_ an ORM (no query builder api), as well as because it returns _pure_ business objects (instead of db-aware objects).

[0] https://github.com/craigmichaelmartin/pure-orm

Yeah, ORMs have grown to mean more than mapping relational data to objects. An example of "just" this mapping can be seen in PureORM[0].

[0]: https://github.com/craigmichaelmartin/pure-orm

The things I've found positive about ORMs are exactly that mapping of results to business objects. The things I've found "not worth it" are the query-building APIs baked into the objects. These principles can be seen in a lightweight ORM I made, PureORM [1].

[1] https://github.com/craigmichaelmartin/pure-orm

Or use a "pure orm" (mapping to plain business objects) without a query builder - thus writing native sql and receiving nicely structured objects from the results (eg https://github.com/craigmichaelmartin/pure-orm)

> Fortunately, there are tools out there that solve the "mapping tables to objects" problem without trying to control all access to the database

In javascript land there is PureORM which seeks this balance (https://github.com/craigmichaelmartin/pure-orm)

The desire for the object mapping (to pure objects, not db-aware objects), while having an aversion to query building APIs led me to use https://github.com/craigmichaelmartin/pure-orm - where native, unobstructed SQL is written in a "data access layer", which returns pure "business objects" to be used in the app's business layer.

Hmm, yeah, but I think more than just not using a query building api, I prefer pure result objects. Even when dropping to SQL, the result objects are still database-aware objects. I prefer distinct layers between the business domain layer and the data access layer. Having a data access layer return pure business objects allows for this decoupling, but maybe I'm being to strict and forcing a distinction where there doesn't need to be one?

In an ORM, the returned objects from even raw SQL is still ORM objects (database-aware objects). I prefer keeping the business logic layer distinct from the data access layer, so I prefer for the return objects to be pure business objects. Maybe I'm being too anal and forcing a distinction where there doesn't need one?

Wow, that sounds like a really neat approach!!