AlaSQL.js – JavaScript SQL Database for Browser and Node.js

https://github.com/agershun/alasql

by truth_seeker • 8 years ago

120 43 8 years ago

github.com

untog3• 8 years ago

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.

Klathmon6• 8 years ago

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• 8 years ago

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

untog3• 8 years ago

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

Agreed. It's not easier to use though - almost everyone ends up bundling 10s of KBs of code just to wrap around it and make it useful. That doesn't seem great to me.

tracker14• 8 years ago

SQLite is already likely the most widely distributed software library in the world. It's in most browsers, it's in both major mobile platforms. It's in cars, planes, boats, trains, and probably in more than one software on your desktop, if not your desktop OS/platform itself. It's also one of the most thoroughly tested libraries on the planet.

In any case, I would rather have the W3C, etc. just setting on a minimal SQLite version implementation as a baseline. Or, similar to JS spec now follow with the minimal active version in major browsers. MS IE/Edge was the main holdout, and they're going with Blink (Chrome) based builds now.

As to AlaSQL, I'm curious how it compares to an emscripten build of SQLite.

lucideer• 8 years ago

it's just too much work.

Creating two+ independent implementations before allowing the spec to be adopted may be too much work, but the same would be true of HTML5 or modern DOM specs to implement from scratch today. Fighting to ensure that there are multiple implementations of standards is a noble goal (incidentally, a fight we're in dire need of for HTML/DOM), but expecting these implementations to materialise fully formed for new standards is a severely limiting requirement.

Without that requirement, supporting WebSQL would be less work for browser makers and web developers alike. Who knows, competing implementations might even have followed down the line had the spec. been adopted.

mzarate06• 8 years ago

Agree. And while IndexedDB deserves credit, I cringe a bit every time I see a SQL implementation in JS. There's clearly a SQL need for developers, so I still feel we missed an opportunity w/WebSQL.

To supplement, see my 2015 comment in response to Lovefield: https://news.ycombinator.com/item?id=10197672

virtualwhys2• 8 years ago

And as a result, we're having to implement our own relational databases. In JavaScript. 4-5 years later.

Now nearly 10 years later. The notion that a WebSQL-like library would be created on top of IndexedDB to replace the deprecated API has proven to be utterly groundless.

It's hopeless, how on earth will a bloated JS library compete with the beast that backs WebSQL? Sqlite, a native C application, just blows everything else out the water. Table joins, window functions? Can't even think the thought with anything built on IndexedDB.

Worse, in the same way that many languages these days compile to javascript, so too do server-side DSLs generate SQL (see Slick, Quill, Esqueleto, LINQ to SQL, etc.). Wouldn't it be nice to share the same model and sql statements on client and server? You know, offload complex aggregation tasks to a native C application designed specifically for this task, instead of manually doing it all by hand with reams of error prone boilerplate in javascript.

Interestingly Chrome and Safari, the browsers that dominate the market, after all these years still ship with WebSQL. Perhaps there's still hope...

z3t4• 8 years ago

400KB is not much for a full database implementation, considering Google.com need's double as much to show a logo and a search field.

chiefalchemist• 8 years ago

Yes. But that 400k is in addition to any other assets, payload, etc. That is the total page weight is higher. While Google tops out at a lighter side 400k.

daleharvey2• 8 years ago

WebSQL literally just had a remote code execution bug showing exactly why it was right that browsers decided against WebSQL

https://blade.tencent.com/magellan/index_en.html

Klathmon6• 8 years ago

Specifically SQLite had a remote code execution bug, and since all browsers that shipped WebSQL used SQLite as the backing engine, they all inherited the vulnerability and exposed it to all web-pages out there.

tzs• 8 years ago

Uhm...all major browsers have a long history of remote code execution bugs, and almost certainly still have remote code execution bugs that aren't publicly known yet.

Heck, even if we just consider databases, the IndexedDB implementations in both Firefox and Chrome have had remote memory corruption bugs of the type that are often exploitable for remote code execution, although I don't know if anyone ever actually built such an exploit.

garyclarke27• 8 years ago

Agreed - dropping WebSQL for much weaker inferior IndexDB made no sense to me. Instead of going backwards, there should be a choice for persistent data - Text cookies or Simple KV Doc store or Relational db. I don't buy the dogmatic arguments against SQLite which is Open Source software of the highest quality - even if a major bug is discovered, there is always the option to disable it, anyway surely surely the likes of Google would have every incentive to help fix it quickly.

netghost• 8 years ago

I suspect that a smaller builds could be generated. There's a lot of functionality like reading from a sqlite db or Excel file that you could probably drop to improve the package size depending on use case.

da_chicken2• 8 years ago

Honestly, I'm more surprised that a WebAssembly version of SQLite isn't more commonly used.

untog3• 8 years ago

It would be huge, wouldn't it?

TAForObvReasons• 8 years ago

browsers

The blame lies entirely with Mozilla/Firefox: https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...

WorldMaker2• 8 years ago

Microsoft was also a dissenting voice against WebSQL. It was a team effort (because this is about standards), not just Mozilla's "fault".

SQLite is not a standard, and it would have been an IE6-level mistake to bake SQLite quirks and bugs into the web standard for the rest of time. (It doesn't matter that SQLite is open source, it's still a central source of failure that the web doesn't necessarily need in every browser for the rest of time.)

detaro2• 8 years ago

Just as "entirely" as the blame lies with those suggesting WebSQL not proposing something that meets the well-established and agreed on expectations for a web specification, and not fixing that issue when it was pointed out.

dukoid• 8 years ago

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?

Keverw2• 8 years ago

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/ 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• 8 years ago

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

Keverw2• 8 years ago

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!

chatmasta• 8 years ago

SQLite can also be compiled to wasm which has some cool use cases for syncing with backend data stores.

Elect2• 8 years ago

Maybe better for hybrid app dev.

babaganoosh89• 8 years ago

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.

RobinL• 8 years ago

Interesting that Mike Bostock posted this today: https://beta.observablehq.com/@mbostock/sqlite

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

AlaSQL.js – JavaScript SQL Database for Browser and Node.js

Related Stories