Hacker News Reader

Comment by austin-cheney | Hacker News Reader

Most of the 4 justifications mentioned sound like mitigations of otherwise bad design decisions. JavaScript in the browser went down this path for the longest time where new standards were introduced only to solve for stupid people instead of actually introducing new capabilities that were otherwise unachievable.

I do see some original benefits to a VFS though, bad application decisions aside, but they are exceedingly minor.

As an aside I think JavaScript would benefit from an in-memory database. This would be more of language enhancement than a Node.js enhancement. Imagine the extended application capabilities of an object/array store native to the language that takes queries using JS logic to return one or more objects/records. No SQL language and no third party databases for stuff that you don't want to keep in offline storage on a disk.

View on HN

  > I think JavaScript would benefit from an in-memory database.

That database would probably look a lot like a JSON object. What are you suggesting, that a global JSON object does not solve?

Whether it is an object, array, something else, or a combination thereof is a design decision. It is not so much about the design of the structure, which should be determined by execution performance considerations, but how information is added, removed and retrieved. Gathering one or more records from a JSON object, or array index, by value of some child property somewhere in a descendant structure of the instance index always feels like a one-off based upon the shape of the data. That could just be a query which is more elegant to read and yet still achieves superior execution performance compared to a bunch of nested loops or string of function array methods.

The more structures you have in a given application and the larger those structures become in their schemas the more valuable a uniform storage and retrieval solution becomes.

Okay, what would your solution look like?

    from cities select state where name='Chicago'

isn't really different from

    cities.filter(x=>x.name=='Chicago').map(x=>x.state)

Thinking small. In SQL databases a well put together database instance will typically have tables that with a single incrementing primary key column and some secondary key columns that point to unique records on other tables. That is the relational part of RDBMS.

Its not about what it looks like. Arrays have fancy functional methods, but not object structures. Its more about whether it executes faster and comprises fewer steps to read/write. A real case in my application is get all ports associated with unencrypted sockets associated with servers of a given type and sort the output in a manner chosen by the user. The data in this case is in different unrelated objects whose properties point to each other in various ways by identity, because each server and socket uses hashes for unique identifiers.

That's a great idea - why not apply it to all JSON objects? In a way, we can already access a JSON array element by position. So all that is missing is a way to push a new element onto the array such that it:

- Assigns an immutable ID to the element, even if additional elements are added or removed.

- Returns that element ID when pushing.

Each "table" would be a top-level array item.

As for JOINs, I can think of a few syntax that are already supported, but none that I like. Any ideas?

sorted maps with log(n) access.

Why would you want a language enhancement for that, rather than just writing it in JS code? (or perhaps WASM)

> As an aside I think JavaScript would benefit from an in-memory database.

isn't that just global state, or do you mean you want that to be persistent?

Like indexedDB but in Node?

Reply on news.ycombinator.com