I'd agree with some of the existing web APIs. But I think some web SQL API
should be built-in.
Why? Because it's a very common pattern. Almost fundamental. Take any project more complex than a toy calculator, and you'll quickly find places where the authors are hand-rolling relational operations.
Does your app have an array of records in memory, which it then searches for values, filters by conditions, and/or sorts? I'd give it a 50/50 chance that if you replaced that array with an in-memory SQLite table, and all operations on it with SQL queries on it, the result would be less code, more readable code and better performance[0].
It's not just the web - I'd argue that programming languages in general should all embed first-class in-memory relational database engines. It should be a part of the language standard - if it's easy to write this:
struct Foo {
int bar;
date baz;
string quux;
};
//somewhere in something
Array foos;
it should be easy to write this:
table foos;
(or some other, better way of describing intended data access patterns)
and get a thing that can be efficiently queried, filtered and transformed along dimensions specified, with the compiler turning your request into efficient bytecode/nativecode. Doesn't mean you have to write queries in vanilla SQL - there are more composable syntaxes out there. But arbitrary loops and map-reduces aren't that good either.
When you start looking at your data processing code as database operations, you'll see it everywhere. That map/reduce/zip blob? That's a JOIN query. That struct you're keeping in your event loop, that looks like:
struct Schedule {
Array tasks;
PQueue toRun;
};
that priority queue is an index on the tasks array, and looking at its front is just SELECT id FROM tasks ORDER BY priority LIMIT 1;. That Entity-Component-System pattern you're using in your videogame? That's
literally a relational database. It was conceived of as such (and for massively multiplayer games, is often implemented as such). Wouldn't it be nice if the ability to express this came built into the language? With a column-oriented option for improved performance, too?
--
[0] - It's trivial to add indexes to SQL table. The engine will maintain them for you. Nobody habitually adds indexes to their own regular variables. They, along with the code to maintain them, would manifest as extreme code bloat. Meanwhile, in-memory SQLite is freakishly fast. If you're measuring performance in Python/Ruby units, you won't even notice the FFI overhead.