151–160 of 227 posts
James is one of the world's great techno-adventurers, & getting to para-socially share in wild adventures like this makes living on Spaceship Earth more lovely & lively! James has also done cool projects like sweet.js macros, helped kick off Firefox devtool's transition to react (iirc), oh and lead the basically industry standard JS formatter Priettier project. I'm forgetting a dozen other things over the years but i…
Fascinating. I'm really curious what the use case is that so many people seem to have. Why do you need so much data in the browser, and to be doing queries and data manipulation there? Where does the data come from? Don't you need to sync it back to a server somewhere?
This lets you write any Serious App with "single-player data" as offline-first (though yes you still need to handle syncing to the cloud somehow – jlongster has done some very cool stuff for that too, looking forward to him sharing more about that).
Earlier quoted context omitted.
I view the "standards" argument as a red herring for building a NoSQL db in the browser. Which, to this day, is slow, buggy and requires third party libraries to be usable [1] For those who are able to stomach an uncomfortable political history instead of an easy, technical answer, you can take a look at [2]. It's interesting that 7 years later, many the folks who pushed hard to get rid of SQL in favor of NoSQL seem…
Having worked with IndexedDB quite a bit at my job, I can level three criticisms at IndexedDB. 1. The API is the dogshit hot mess you'd expect for a pre promise/async API. 2. The lack of partial/computed secondary indexes. 3. Apple/Safari does EVERYTHING in their power to break it. I refuse to believe it's incompetence at this point, it's actively malicious.
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…
> It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). This is almost certainly not even close to correct. There are substantial reasons why it wouldn't be a good idea, but this might be the biggest one: it's very hard to adequately sandbox an external C library. (... and, also, Apple probably would prefer that the web didn't exist at all, but that's a different pandora's box...)
This is also how I justify my opinion that the "no independent implementations" was more of an afterthought excuse, and less of a primary motivation on Mozilla's part.
(I'm a little pressed on time here, but I could probably find more examples if I had more time to search... Sorry!)
Quoting Jonas Sicking from a W3C IRC log[0]:
> we've talked to a lot of developers
...
> the feedback we got is that we really don't want SQL
Quoting Maciej Stachowiak from the "public-webapps@w3.org" list[1]:
> Hixie has said before he's willing to fully spec the SQL dialect used by Web Database. But since Mozilla categorically refuses to implement the spec (apparently regardless of whether the SQL dialect is specified),
...
> At the face-to-face, Mozilla representatives said that most if not all of the developers they spoke to said they wanted "anything but SQL" in a storage solution.
The comments relating to JOIN in the comments on Mozilla's blog post comparing IndexedDB and WebSQL[2] betray the anti-SQL (and, arguably, anti-relational database) stance at Mozilla.
Mozilla's people didn't like SQL, so any excuse for dismissing WebSQL (or even a simplified SQL dialect that didn't have the "quirks" of SQLite) was a foregone conclusion.
And now here we are shipping >1MB transpiled WASM payloads around when we could have agreed on a query language feature set implemented in native code using a consistent back-end standard storage format.
[0] https://www.w3.org/2009/11/02-webapps-irc
[1] https://lists.w3.org/Archives/Public/public-webapps/2009OctD...
[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...
Having said that, I do like the idea of Sqlite in the front end for localstorage.
Earlier quoted context omitted.
PWA is a Google term, but the whole web app thing is older than even the native app store on iPhone.
Google may have coined the term (not sure about this), but it's far from their own thing [1]. PWA should've been a blanket term for a set of standards and guidelines for developing web apps. Those include progressive enhancement, which I don't think most people would expect. Unfortunately, the term has been co-opted to mean "website I can install/pin as an app". Again, Google is probably to blame for this, but AFAICT…
And "progressive enhancement" just means "being written in such a way that you'll work with a core set of APIs — all the way down to 'no javascript support' — but will take advantage of further APIs if they're available." Where the app forms a sort of Russian nesting doll of functionality, where it "launches" with just the innermost layer (e.g. just server-rendered HTML), and then in turn each new layer is enabled if possible (i.e. if Javascript is enabled, the browser will load some JS from a tag that will then take over the DOM and turns the page into a SPA; etc.)
It's just a further refinement of the older concept of "graceful degradation", where the gracefully-degraded experience is delivered at the start, and then bootstrapped out into the non-degraded version.
Under this definition, the "further layers of functionality" provided to "installed" webapps in some browsers are just a specific kind of progressive enhancement. The app detects that it's being run "installed", and takes advantage of that. (And before that, the browser detects that the app has such a layer, and therefore treats the webapp as "installable.")
Thus, all "installable" apps are PWAs. (But not all PWAs are "installable"!)
I would note that webapps like Slack — i.e. webapps that have both web and "native" versions, where the "native" version is just the same remote webapp from the web version, loaded in a special browser that exposes extra capabilities that the webapp then takes advantage of — are also PWAs by this definition.
Earlier quoted context omitted.
The sad irony is that if HN is anything to go by, SQLite is super trendy now. I feel like "just sqlite" was really a very practical idea and now, because it has already failed once, we can‘t really try it again, or can we? Having the spec basically be "bundle one particular piece of software into the browser" might not be in the spirit of web standards, but on the other hand SQLite is so widely bundled into everythin…
> The sad irony is that if HN is anything to go by, SQLite is super trendy now. If you look at the recent StackOverflow survey, the majority of the developers only have around 5 years of professional experience in the industry. SQL has been around since the 1970s and is still around in force for reason. There's a good chance a lot of developers, especially the enormous number on the front end, do not have experience…
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
Sounds more like SQLite in the browser.
Did you read the article? That's literally what it is.
Earlier quoted context omitted.
Yeah I think so too. It‘s a cliche by now to say these things go in cycles but they do. If we like this part of the cycle, let‘s ride it and let SQL get hyped, even though its been around forever and never went away.
What gives you the confidence that it's going on circles? I cannot see our industry repeating the mantra that NoSQL solves all our persistence problems ever again. There are use cases for them, but not everything is a good fit and I'm pretty sure we found that out as an industry. I'm sure there are always going to be individuals that will claim that they're better at everything, but that doesn't really mean anything.…
That argument was more usually a straw man than a good faith belief.
On the other hand the belief that SQL will solve all our problems seems to be legitimately held by some people.