Live data from Hacker News

A future for SQL on the web

jlongster.com

221–227 of 227 posts

Re: A future for SQL on the web

#221

Earlier quoted context omitted.

The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Hindsight shows that was entirely correct, as SQLite bugs were then found that could be exploited directly via WebSQL, Firefox of course was not vunerable. ( https://hub.packtpub.com/an-sqlite-magellan-rce-vulnerabilit... ) As a sidenote, I worked a lot with the WebSQL API and it was n…

> The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Looks at Chrome

It’s funny that the top comment points out the obvious-- people want SQL in the browser-- and a NoSQL author immediately has to jump in to claim that SQL in the browser was wrong all along.

I think the NoSQL and MongoDB folks are worried for their careers.

Re: A future for SQL on the web

#222

Earlier quoted context omitted.

Disagreed, this is a dangerous line of thinking that leads to using technologies like gwt, Vaadin, Blazor, Flutter or others that try to turn the browser into something that it's not suited to. Sure, there could be cases where you have absolutely no alternatives to do something really specific, but in those cases I'd first invite you to reconsider whether what you're attempting to do actually needs to be a web app. O…

> why not have it be a native app instead of a bundled browser app, for excellent file size There are other valid arguments, but "use a native app for smaller file size" specifically doesn't make sense at all - the opposite is true. While webapps may be larger than simple web pages, they're still far far far smaller than native apps, and using service workers etc, you do only pay the download size for a web app once,…

That might be an apples to oranges comparison in some regards, to be honest.

Using native UI frameworks will almost always yield smaller file sizes than the equivalent implementation in any of the web technologies, regardless of whether served as a webpage, or bundled in a WebView or something similar (with few exceptions, one of which is listed below). Just consider a WinForms/GTK/Qt or a similar application in contrast to using React/Angular/Vue and including those within Electron, or even loading them in a web browser.

Many of the mobile applications out there actually include hybrid technologies (like Ionic, React Native, Xamarin or anything else of the sort), since nowadays telling a company that you'll have separate codebases with OS native widgets for iOS, Android and others would not be met positively. Therefore, concessions are made to speed up development, at the expense of having more abstraction layers and larger bundles.

One aspect in which you're probably correct, however, is that technically the web indeed affords you the possibility of having pretty good download space savings, if you choose which forms to make user download, as opposed to including all of them in the application. For example, if you have a billing form that actually needs 50 different variations based on countries and regions, and include them bundled into a native app, then on the web you'll instead be able to just download the one that you need dynamically. That said, none of this is alway easy, hence Twitter and Uber both employ a large number of engineers that work on screens like that, even if many people won't even see them.

My point here is that there are many different approaches and technologies that can be used, "native" in the context of my message meaning an application that uses the OS UI and widgets directly, without reinventing the wheel or attempting to encapsulate cross platform or web technologies within it. Of course, it's perfectly understandable and valid why companies that are highly focused on their own brands and shipping quickly don't necessarily adopt that approach.

Re: A future for SQL on the web

#223

Earlier quoted context omitted.

I wish these bookmarks extended to other browsers on iOS. It's already crazy they can't ship custom rendering engines, but basically this in and of itself could be considered anticompetitive (only Safari bookmarks can be exempted from this GC process) lol!

I think all home screen apps run on the system webview, there are no “safari bookmarks” in this context.

you can only add bookmarks from the home screen from Safari. Chrome, Firefox, etc do not have this capability

Re: A future for SQL on the web

#224
> But that’s it. That’s the only catch.

I'd like to add one drawback with this solution: Complexity.

From my experience, complexity can easily lead to more problems than what it solves. With all the "blackboxes", e.g., WASM, JS, SQLite, IndexDB, ..., it might be hard to find bugs. Most of the tools used are somewhat stable and mature tough. SQLite, for example, has a whooping 100% test coverage (line coverage at least).

Re: A future for SQL on the web

#226

This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…

You can still use WebSQL in Chrome & Safari and use a polyfill backed by IndexedDB for Firefox using YDN-DB: https://yathit.github.io/ydn-db/doc/setup/polyfill.html

Re: A future for SQL on the web

#227

Earlier quoted context omitted.

Did you read the article? That's literally what it is.

Yes, and it literally says "SQL on the web" and "SQLite on the web". Are we really confusing "the web" with "the browser" now, especially since we use "the browser" to implement apps that don't have a need to access "the web"?

Ah, alright fair.
Post reply on HN