IndexedDB is far bigger news here. Does this mean saving Blobs in IndexedDB is finished?
I hope this doesn't mean Firefox is going to stop working on it because their implementation is much slower than in Chrome and IE (albeit Chrome is using the old spec).
At this point we are unlikely to switch to leveldb, work on that has stopped. During integration and testing for leveldb we made a lot of progress on sqlite optimzation and the leveldb advantage diminished significantly, if not disappeared.
(Notice that the bug you referenced hasn't had any real progress since it was filed in August 2011, and work has stopped on the parent bug for integrating leveldb.)
I don't know much about the particular performance problem you're referencing, but I doubt it is as simple as sqlite not being fast enough.
I write an indexedDB library and have 25 unit tests that have multiple operations per test, let's say an average of only 2 per test. So about 50 operations, mostly just get or put. Chrome takes about 1 (when warm) to 1.5 (cold start) seconds to run all of the tests, Firefox takes 3.5 (warm) to 5 (cold). IE10 is phenomenally fast, less than a half a second even when cold.
This is some combination of slowness from pulling js from the cache, raw js speed, and indexedDB speed. I assumed it was mostly the latter but I could be wrong.
I was about to agree with you, for PouchDB I have a test suite of 460 tests which take around 20 - 30 seconds and are mostly indexedDB operations, I remember having to increase some timeouts to have tests pass in Firefox
But I just ran the test suite again and after a few runs, there was little difference in timing, firefox even came faster a few times.
And this is in latest stable, I cant test nightly yet due to some api changes, and I know there was a lot of work done on idb performance improvements last week.
Ugh. We should get rid of prefixes already. They are a hassle for web developers, and reality is the web moves so fast that what's supposed to be "experimental" may be very quickly put into production use. Removing them would not prevent changing the syntax of a CSS property. Prefixes are bad anyway because they ensure only 4 engines can be ahead of the curve, unless web developers decide another matters enough to add the prefix for it.
Edit: Actually, if we don't get rid of prefixes entirely, we should get rid specifically of vendor prefixes. Using -experimental- or -x- is fine with me. Just don't segment by vendors so only some browsers are explicitly supported.
I don't think you understand why the prefixes are there. CSS was designed in a way that things should either work or not. There shouldn't be different ways to interpret a property. With browsers battling over several syntaxes for CSS3 implementation, the last thing we want is to have webdevs build a separate stylesheet for every browser out there, because (for example) "transform:" works different on Firefox 3 than on Firefox 4, and Chrome's implementation is also different. The prefixes help a lot here: you can group all these different stylesheets into one by using the prefixes, and once the standards are finalized they'll just use one syntax that can't be interpreted any other way.
Let's say that you have a property that takes in two color parameters, crazy-coloring. Webkit implements crazy-coloring: bgcolor fgcolor; Gecko implements crazy-coloring: fgcolor bgcolor;.
How do you propose we differentiate these and know what the designer meant? That's why we have prefixes, until it's standardized.
Usually we don't end up with cases that are that drastically different. And in that case, now only Webkit, Gecko, and maybe Trident and Presto are considered. Other, less popular rendering engines are rarely included in the set of prefixed properties, excluding them from the ability to use new features.
Webkit:
background-image: -webkit-gradient(
linear, left top, left bottom, from(rgba(50,50,50,0.8)),
to(rgba(80,80,80,0.2)), color-stop(.5,#333333)
);
How would one properly differentiate between browsers implementing functionality differently in this case without prefixes? The only option would be to wait years for standards to be finalized and then implemented.
Because of the prefixes, yes the browser knows which properties to skip. But you were advocating removing prefixes, so I'm wondering how browser are supposed to differentiate between properties?
Wait so you want them all to use the same prefix? So you'd have five properties called "filter:" or "background-image:"?
If my gradient looked bad in Mozilla, how on earth would the I know which property to change? They'd seem identical unless I memorized every single browser specific implementation of every CSS property.
Code should be self-documeting. You're proposing we remove something that serves to differentiate between properties in favor of simply adding the exact same information in the form of a comment.
Eh? Did you even read what I posted? Browsers ignore CSS they don't understand, hence you can put several versions of a rule, and a browser will use the one it understands.
I hope this doesn't mean Firefox is going to stop working on it because their implementation is much slower than in Chrome and IE (albeit Chrome is using the old spec).