
AlaSQL.js – JavaScript SQL Database for Browser and Node.js - truth_seeker
https://github.com/agershun/alasql
======
untog
This is very cool. But Github tells me that the minified version is still over
400KB.

I really wish browsers hasn't decided against WebSQL and replaced it with
IndexedDB.

~~~
Klathmon
As much as I also wish we could have a full SQL engine in browsers, it's just
too much work.

The web as a platform thrives on multiple implementations, even going so far
as to require it for new standards in many areas.

All implementations of WebSQL were basically a lightly wrapped SQLite, and
that meant that a bug in SQLite was a bug in all browsers, and design
decisions in SQLite would impact the entire web ecosystem, and that was
consitered by many involved to be a bad tradeoff.

IndexedDB is much simpler to spec out, much simpler to build multiple
implementations of, and much simpler to maintain and improve over time.

In a way it's punting the problem down to userland, but userland doesn't need
to abide by the same rules and restrictions as a blessed standard does, so it
makes sense to push more complexity down to that level.

400kb is a lot to pay, but it just goes to show how complex an SQL engine
really is. Paying for that in the form of a JS bundle download is one thing,
but having that complexity in every browser means a larger attack surface,
larger maintenance surface, and at the end of the day still doesn't completely
remove the need for things like AlaSQL.js (which may target a different
implementation than WebSQL)

~~~
vandorjw
I think it is too bad. Almost all browsers except for Firefox use Chromium
(blink) as their browser engine. That means that a bug in Chromium is a bug in
almost all browsers, and design decisions in Chromium impact the entire web
ecosystem.

I agree with your above comment, and we can argue that working on a single
web-engine might lead to less duplicated work for Front-End devs, and less
bugs in the web overall.

Given that sqlite is the most widely deployed DB already, making it part of
web browsers doesn't seem like a huge deal to me.
[https://www.sqlite.org/mostdeployed.html](https://www.sqlite.org/mostdeployed.html)

~~~
Klathmon
But the bug aspect is only one part of it, the other is that it ties the
future goals of the projects together.

What happens when the web wants to implement some special optimization or
security addition but SQLite doesn't want or support being used that way? What
happens when SQLite makes a breaking change in a future version that might
make sense for them, but would break a large number of web apps?

Once something is in the web standards, it's VERY hard to drop support for it.
SQLite might make sense now, but what about in a decade?

No matter how you slice it, WebSQL has the ability to become a massive
maintence liability, one that all major browsers agreed was too significant to
codify into a standard.

~~~
judge2020
The user seems to be complaining more against Chromium's dominance and not
about SQLite being left out of the web ecosystem.

You can replace every mention of "SQLite" in your comment with Chrome (or
Google) and suddenly you're agreeing with the comment instead of expressing
your opinion against it. Chrome currently dominates web standards, and other
browsers must keep up or risk losing even more market share to Chrome.

~~~
Klathmon
But that's not exactly something that Chromium or the web standards bodies can
change... (well, Chrome might be able to, but i'm not so sure it would be
beneficial)

Many web standardization systems already require multiple implementations of a
feature before it can become "standard", and by that nature some will have to
implement it first. Chrome has Google behind it, and they have a lot of money
and a good reason to spend it here (the better the web is as a platform, the
better their company which is based on the web works).

But there are plenty of examples of where Chrome's "dominance" didn't allow
them to just unilaterally push through APIs or platform changes. PNaCl failed
and we got WebAssembly which is much better. The original version of ShadowDOM
was shot down and it left Chrome behind other browsers when it came to the
true implementation. HTML Imports were again something chrome implemented
first and is currently being removed due to it ultimately not working out well
and the platform as a whole moving in a different direction. Hell most of the
WebComponents spec was changed or removed before it started getting in other
browsers in a major way.

Sure, Chrome could just stop improvements altogether, but that seems like a
poor solution. One thing I'd love to see from Google is for them to pull their
(in)famous move of eating their own lunch. I'd love to see them pull a Servo
and try to spend the time and money creating a new rendering engine from
scratch to compete with their own Blink engine.

------
Keverw
I am researching for a project idea I have and was actually looking up in
memory SQL databases for node last night to store and sort data instead of
creating a object and custom functions to filter it.

I came across [https://nanosql.io/](https://nanosql.io/) also which I am
leaning more towards. Not to the point yet to play with either yet but it
seemed like nanosql had better documentation and also less issues opened on
Github right now.

Kinda odd how when you look up things or think of things you see signs of
them... Just wow'ed to see something I was looking at last night be #4 on the
HN homepage... I know people talk about positivity and the law of attraction
but starting to believe more and more in it where thoughts and focus becomes
reality.

~~~
estsauver
If it's on the backend, why not sqlite? It's pretty great!

~~~
Keverw
Just temporary data. However SQlite does have a In-Memory Database support,
almost forgot about that. But probably SQlite would be a bit bloated to use
for this part anyways. This being native to JS and even typescript support
just seem nice... However SQlite is more battle tested, was watching a tech
talk about it once and they even use it for airplane computers!

------
RobinL
Interesting that Mike Bostock posted this today:
[https://beta.observablehq.com/@mbostock/sqlite](https://beta.observablehq.com/@mbostock/sqlite)

I'm not sure how the two compare...

------
dukoid
Persistence seems to be via files... So I suppose just as for Lovefield, all
the data needs needs to be loaded before use? This also seems to make sharing
between tabs tricky?

------
babaganoosh89
Does this use web workers to access the db? Otherwise I'd worry about queries
blocking the main thread, especially as the database gets larger.

------
Elect2
Maybe better for hybrid app dev.

