171–180 of 227 posts
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?
Hmm... I was in the middle of rewriting an application of mine from JSON stringify into localStorage to IndexedDB, but was having issues with the API being so clunky. This is a tempting alternative. It does increase size from ~200kb by a whole mb, but the app's usage patterns are such that people open it and then use it for extended periods of time in the background.
Hmm... I was in the middle of rewriting an application of mine from JSON stringify into localStorage to IndexedDB, but was having issues with the API being so clunky. This is a tempting alternative. It does increase size from ~200kb by a whole mb, but the app's usage patterns are such that people open it and then use it for extended periods of time in the background.
Careful with IndexedDB. There was a post here recently about how it is 100% broken on safari right now.
The design is very much a 00s throwback with a lot of density and power compared to more modern apps in the same category, so Mac users are unlikely to like it anyway. I was just tired of the older apps lacking modern features I like while the apps with the modern features were clearly mobile/touch first and so much slower for bulk operations than their older competitors as a consequence.
Earlier quoted context omitted.
I think sql is a bad fit for front end code in js. We may have ended up with another fight over ORMs. The Vietnam war of computer science as I think it was called.
How else would you suggest full applications run in the browser. Desktop apps make use of SQLite all the time even when they are mostly server backed. An example is that Telegram maintains a local db which stores the most recently accessed content so you can scroll through past messages and media without having to request them every time you view them.
Earlier quoted context omitted.
Another, probably not insurmountable, issue with SQLite in the browser (without having a formal specification that could produce cross-language alternatives): Using SQLite results in a new, built-in reliance on a C library. Even though most languages can use C library bindings, it does present some issues in some build scenarios, such as static builds, and, given the enormous scope of SQLite, would prevent anyone fro…
I find this an odd comment. Is a 100% Rust browser something anyone is clamoring for? At any rate, if that really is your goal for some reason, rendering engine is going to be your first problem anyway. Then a JS runtime.
A 100% memory-safe browser is definitely something I'm clamouring for.
> At any rate, if that really is your goal for some reason, rendering engine is going to be your first problem anyway. Then a JS runtime.
Mozilla is working on the rendering engine. Memory-safe JS runtimes already exist (e.g. Nashorn).
Earlier quoted context omitted.
PWA are explicitly exempt from the data storage wipe behavior[1]. So there's that, at least. For now. Although I agree that it's a fairly minor win in the grand scheme of how handicapped PWA's are on iOS. And like you said, the lack of install prompts and tucking away the PWA "installation" option in the share menu makes it less than intuitive and requires manual awareness efforts by devs[2]. [1] Last section of http…
That’s only half true. PWA are exempt from data storage wipe behaviour only if they have been added to the Home Screen. And as your second article points out: > It’s important to ensure that our iOS visitor is using Safari because iOS doesn’t permit other browsers to install our awesome PWA’s! So if the user is using Firefox or Chrome etc browser, they can’t do it. And since all browsers have to use WKWebView, the li…
Like wish granted! You can now use Blink and V8 on iPhones! But…
* They still are required to delete website data after 7 days.
* They must distribute add-ones through the App Store.
* They still can’t run workers in the background because the browser is slept like any other app.
* They have to use Apple’s notification service like any other app.
* They can’t install things to the Home Screen because no other app can.
But yayyyy. Blink!
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…
My feeling is that the web apis try to do too much. Why do we need a webSQL api. Why do we not just let websites create a file and then they can provide whatever kind of library they want. They could package a WASM version of sqlite and just work like they would as a desktop app. That way you never have to deal with browser incompatibility or unchangeable specifications.
Earlier quoted context omitted.
> 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…
If anyone else is curious https://insights.stackoverflow.com/survey/2021#developer-pro... Most people responding have 5 or more years of experience
Earlier quoted context omitted.
Any sort of decision point that tends to vary between our customers. We are getting really tired of maintaining custom code piles.
By that you mean several piles in different languages? Or one pile for each customer?
Earlier quoted context omitted.
first thought, was there a "standard" for key/value stores? mongodb the reference implementation? overall, if you looked at HN like five years ago, every DB headline was key/value, mongodb, maybe some cassandra / couchdb, links to the "web scale" cartoon. these days, it's SQL SQL SQL, with a heavy dose of SQLite and PostgreSQL. SQL survived the key/value fad despite the nebulousness of a workable "standard" (yes ther…
I think sql is a bad fit for front end code in js. We may have ended up with another fight over ORMs. The Vietnam war of computer science as I think it was called.