Mozilla hasn't made me very happy lately with their "choice" tactics. Resetting people's default search engine to Yahoo of all things on update was very opaque. Also the AMO signing fiasco, Pocket and Hello. Feels like an "It's only okay when we do it" kind of thing.
I think reasonable criticisms were made regarding some of those, like Pocket.
However, Australis for example was a large redesign of the UI. I'm not sure how you can support an opt-out, as that would mean supporting two codebases - two different and separate UIs, at once.
Regarding bundling of DRM, it isn't bundled, but it is downloaded on demand. This is a sad thing even so, but Google, Microsoft and Netflix just left other browsers no choice when they invented, standardized and shipped EME DRM. Mozilla fought DRM, but lost.
Australis wasn't necessary at all, though. It broke my ability to keep tabs on the bottom, it forced the refresh button into my URL bar (the opposite end of my other navigation buttons ... making it much more annoying to use), it killed my stop button, it took the bookmark icon out of my URL bar, and it broke my ability to see full page titles.
None of this enhanced anyone's productivity: it was change for the sake of change. That sort of thing is fine, but you should always offer a simulation of the behavior people are used to when you have millions of users. And if you don't have the manpower, then maybe reconsider making unnecessary changes in the first place ... nobody was abandoning Firefox because its UI stayed the same. Microsoft understood this at least until Windows 7, which you could easily make look and feel very much like Windows 95. But sadly the new trend in tech is to constantly force superfluous UI redesigns on users all the time with no opt-out. You see it with Google Mail, Skype, Windows, iOS, Android, Firefox, Gnome 3, on and on.
It's not just people hating change: there are people with disabilities that learn how to use this software, and changing things because some designer decided the UI "needed a refresh" can really destroy someone's entire workflow.
It would have even been okay if they had made it a bit more flexible in configuration, but they didn't. We lost a lot of control over how the UI operates. And so now I have to use yet another extension (Classic Theme Restorer), which is a bit buggy and might be discontinued at any point in the future.
And thanks for the correction on the DRM. But I wouldn't say they lost, I'd say they caved in. They weren't forced to support it, they chose to for the sake of their market share.
I don't know if you're willing to consider it evidence, but I think Apple's success is in large part due to their software and their UI's. iOs in particular.
Also, user interfaces might be closer to fashion than you would think! If you consider Windows XP's look. Imagine Windows 10 looking like that. Or consider Windows 8's different looks compared to Windows 7's. Or Google "material design" on Android Lollipop. Dang, this is exactly like fashion! :D
Yep, this is what I think too. The Pocket and Hello case could at least have a disable option, even Google allows you to disable the new features that it brings in Chrome like Google Now and more recently the "Ok Google" hotword detection.
However, the Australis case is much more complicated. An UI is tons of code, if Mozilla opted too maintain two different codebases they would need to update both everytime they added a new feature. This would be a maintenance nightmare, to say at least. I think it's ok to have this feature as a separate extension, maintained by people that actually care about the older interface.
> The Pocket and Hello case could at least have a disable option
I really don't think burying an opt-out option justifies these things.
This is the same tactic used to push malware in installers, Ubuntu's farming your search results to Amazon, and many of the new Windows 10 privacy intrusions. "You can opt-out (if you know you need to (and you know where to look (and you know about the gotchas like it only applying to enterprise customers)))"
If they were honest, these things would be opt-in. But they're not, because that wouldn't make them their money. (and if you really believe someone at Mozilla isn't getting paid for Pocket integration, then I have a bridge to sell you.)
If you don't want to use it, don't. You can't compare a feature you don't use to malware, which actively causes things to happen that you didn't want to happen. Nothing happens if you don't use the Pocket button.
For some reason, everybody feels like they should have a say in the direction of large Free SW projects, even if they have never contributed.
Some criticisms of Mozilla are fair (even if blown out of proportion, like the Pocket issue), but one can not expect a project to make development even more complex by adding a "revert it because this one guy doesn't like it" button for each change or feature.
As a software dev that's received plenty of criticism as well, I'll just say that when I post detailed complaints about things I don't like, it's not because I want to harm or destroy their software. If I truly hated their software, I wouldn't be using it or talking about it at all. For all of Mozilla's faults, the only real cross-platform alternative (Chrome) is even worse. That one forces silent updates, won't let me download and run older versions, won't let me disable WebRTC, was the inspiration for the new Mozilla UI I dislike, sends a lot of data back to Google, etc.
The problem with not complaining is that when everyone does it, the developers have no idea why 30% of their market share is gone, yet everyone who remained is still happy with the changes.
Further, I think really major software projects like Firefox and Gnome are in a different category. People's livelihoods depend on these software programs. Totally changing things around can have serious effects on people, not just those who hate change.
It's one thing to be a single developer working on a solitaire game and deciding to redesign everything; it's quite another to be a multi-million dollar company with hundreds of employees and tens of millions of users and deciding to redesign everything.
When you care about your market share, have employees that depend upon your success, and so forth ... you really should make the effort to listen to your community of users.
And let's not forget the whole reason we're having this discussion is because Mozilla just berated Microsoft for removing user choice. If you're going to criticize someone for their faults that you're every bit as guilty of, you should expect to be called out on your hypocrisy.
As I said, some of the criticisms are fair. At the same time, the kind of issues that we techies tend to complain about are largely not behind that drop in market share: the majority of those users have moved on to browsers that are worse in terms of privacy and security.
It is a tricky issue and the comparison with GNOME is apt. At the end of the day, the last word belongs to the companies and individuals actually doing the work. We on the outside can still try to convince them, of course.
Practically, it's impossible to maintain one without a proportionally large team that can spend proportionally big amount of time.
As one of most obvious examples (unrelated to Mozilla or Microsoft): there are uncountably many custom Android ROMs out there, left abandoned. And most were merely cosmetic changes or even packaging (like inclusion or removal of certain pieces by default). Usually, unless luck is that there's a large social momentum and a lot of advertising among same-minded people, fork maintainer struggles for a few versions then gives up and surrenders to the upstream way of thinking. Sad but true.
Forking usually happens when a group or individual is unable to steer the direction a project. Having to go on your own is pretty much the opposite of "having a say".
However, Australis for example was a large redesign of the UI. I'm not sure how you can support an opt-out, as that would mean supporting two codebases - two different and separate UIs, at once.
Isn't it frustrating when a major software vendor takes a product you rely on, updates the whole UI in a way that makes the product worse for you and many other people using the desktop version primarily in order to try to make it better for the tiny number of people using the mobile version, and then makes clear that if you don't go for their new version you'll also miss out on critical bug fixes and security updates for the old one within a few months?
Nope, I used Firefox LTS 24 as long as I could. But by LTS 31 (which wasn't very long), we were back to Australis.
And Firefox 24 is missing a whole lot of really critical functionality.
You really have no choice but to trust the random third-party developer of Classic Theme Restorer not to do anything malicious, and pray that he doesn't ever quit.
Sadly, I have discovered that Mozilla and I have very different ideas of what "long term" means.
The irony of my previous post is that both Microsoft and Mozilla seem to be playing the same game now, right down to sub-year "long term" support. You can't really choose whether to have those updates any more, only to defer them for a short while. Anything more than that, and you just have to give up on updating altogether, security updates included, and for a new OS that is even more dangerous than it is for a browser.
Honestly with everything becoming web apps these days, I'm starting to feel it's more dangerous for the browser than for the OS. So many zero-day exploits like the recent Microsoft OpenType bug. And of course, Flash. Enough said there.
I'm already to the point where I don't web surf on my primary development box, outside of localhost (site dev work.)
As long as your firewall seals off all unrequested external traffic (easy with pf), and you don't run untrusted desktop applications, then the only real attack vector is through your browser.
I'm not quite that strict with my main work machine, but I am very careful about what I install on it, and typically my browsing is all work related or the occasional site likely to be very safe (BBC News at lunchtime, say).
I do want to point out that the OpenType issue you mentioned is really an OS bug rather than a browser one, though. It's a good demonstration that ultimately any OS facility that is used by browsers is a potential vulnerability, and crucially it's a cross-browser vulnerability and therefore more attractive to attackers.
What I'd really like is for all my platform software -- OS, browsers, language runtimes and the like -- to focus on stability and quality, with new features taking a secondary role. But I guess that doesn't sell new and shiny to customers^Wconsumers with an Internet-era attention span. :-(
Microsoft is in a different league with Windows 10, however. This was what they dreamed of 15 years ago. Once you install Windows 10, it's no longer your PC, it is Microsoft's.
You can't choose to avoid an update.
Think about that. This means Microsoft can do anything it wants to with your computer:
* change your settings
* farm your compute cycles
* put in advertising
* install a pay gate to charge you per logon
* read your files
* add key loggers
* change your settings at their whim
They'll be able to do any of this whenever they want because YOU, the former owner of the machine, will not be allowed to circumvent or opt-out of "updates."
You haven't upgraded to the latest version of Office? Too bad, we're turning the one you have off.
We just signed a deal with a third party, so that video editing software that used to come with Windows... gone, but feel free to pay for that third party package in the app store.
We noticed you have some MP3 files that we didn't put on your machine. They'll have to go, or you can license them through us.
We're enhancing your security by removing Google Chrome... you see they didn't comply with our updated code signing policies. Sorry.
The last few hiccups with Mozilla are them being the Diet Coke of Evil in comparison.
No, they can't legally do any of the negative things you've listed, and they aren't an organization with a history of criminal action against customers. This brings the OS in line with the behavior of many applications (Chrome for example) in keeping things always up-to-date & secured, and it's done because most users are incredibly lazy and ignorant.
Until recently, Microsoft wasn't really dealing with their users' data. This requires that you trust them. Personally I trust them just enough to use their OS (or rather, I rely on the fact that they know people watch closely what Windows does), but I definitely don't trust them to keep my data.
More precisely I don't trust them (or any other company) when they say they won't sell my data, or spy on me, or use my data against me. Because, when you think about it, there is absolutely no way to verify that they keep their word.
> it's done because most users are incredibly lazy and ignorant.
I don't know why it's acceptable for software to treat all of its users as lazy and ignorant, even if most actually are. All that's going to do is encourage them to find ever new and amazing ways to be even more lazy and ignorant.
Sure, botnets suck, but it's not worth giving up control over our desktops to stop them.
> All that's going to do is encourage them to find ever new and amazing ways to be even more lazy and ignorant.
A lazy person won't do anything more difficult or time consuming than the easiest choice available, and an ignorant person might not even realize there are other choices. So make the easiest and default choice do the thing that is "best" for everyone.
> Sure, botnets suck, but it's not worth giving up control over our desktops to stop them.
I used to agree, but am no longer convinced of this, at least personally. I use Windows and OSX daily, and feel a hell of a lot more secure about my OSX machine. I'd give up some control of my Windows machine to not always assume everything is or will likely be infected at some point, by a known or unknown cause, detected or not detected.
Not to say that OSX cannot be attacked, it definitely can, but overall.. there's little comparison. the relative ease of updates & upgrades, high adoption rates, a very nice app store full of sandboxed apps; it's just a much safer place.
I agree. And I extend that sentiment to their approach to Web Standards a few years ago too, like WebSQL [0] and NaCl [1], Dart [2]. That felt like NIH [3] or some other non-collaborative or ultra-competitive motivation on their part. Not a place of "speak for the Web". IMO, the choice of IndexedDB over WebSQL set the Web back 20 years.
About WebSQL
Firefox already had (and still has) Sqlite dependency (it is uses for bookmarks, history, ...) it is not the issue. The problem is that the Web SQL standard states "User agents must implement the SQL dialect supported by Sqlite 3.6.19." [0] which made agents rely on a outdated dependency and non standard (sqlite is not SQL ansible compatible) SQL. A nightmare for Web standards. They made the right (and hard) choice.
NaCl isn't portable (Mozilla is working on Web Assembly)
Dart excerpt taken from Dart FAQ; question: "Will the Dart VM get into Chrome?" response: "No. Dart is designed to compile to JavaScript to run across the modern web, and the dart2js compiler is a top priority for the team." [1]
Google has the Dart VM running in Chrome and it's called Dartium. If Mozilla had not been so vigorously negative towards Dart the story of Dart and Blink may have turned out differently.
Whining for the poor Google-Goliath, blaming little Mozilla-David, is rich. No comment on the Pocket deal or other recent Mozilla changes. On this tangent about Dart, I'm happy that Chrome people prevailed.
The Dart team is not a large team and not an arrogant team. Led by Lars Bak, they thought to try and make something that ran faster than JavaScript by doing away with 'monkey patching.' Lars and Kasper Lund took all their experience working with V8 to make something that avoided the bottlenecks. Gilad Bracha designed a good working language and it works without many "gotchas" along the way. It's a pleasure to use. The Google Chrome team was not enthusiastic about it even before Blink, as you correctly state, but what I was trying to say is that if the industry hadn't reacted so negatively to Dart because of some percieved ulterior motive by Google, the Chrome team may have been persuaded to put some more thought into it and make it happen. Lars Bak, Kaser Lund, Gilad Bracha and the rest of the team did something cool and don't get any props for it because they work for Google. Such is life. I recall Mozilla disliked it the most, which I assume was driven by you, the creator of JavaScript. Dart was never going to replace JavaScript you know, because even then they were saying that anything that can be written in JavaScript, will be written in JavaScript. JavaScript is unstoppable, but people should look at Dart for what it is, another tool in the toolkit.
It's hard not to personalize things like what Oliver Hunt said in [0],
"The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to."
The general tone Oliver had was akin to saying only little-endian machines should be supported on the Web. Not because of some technically proven deficiency in the idea of allowing big-endian machines, but because "we don't want to." I can only imagine if such logic had been applied to other parts of the Web. Technical problems always have a solution.
Oliver is not me, nor has he ever worked for Mozilla. But you are not the OP, so this is all just more mistargeted drive-by and taking-it-too-personally complaining.
There are not multiple GC'ed VMs in Safari sharing the DOM, so I bet Oliver was talking about things like JSC as another way to script Apple stuff than Obj-C (now Swift). But that's not material to the DartVM/OilPan vs. Chrome issue.
Please read anything I've written on the topic over the years.
Java runs as a plugin, like Flash. It has no deep DOM integration.
Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison.
Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots.
This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount.
Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code.
(Updated to note that LiveConnect is long-gone too. Java is just a plugin.)
I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!
What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.
What aspersions? Let's start with your "Mozilla disliked Dart", full of personalizing words that obfuscate the objective arguments. Just the "dislike" usage is subjective and vague -- and inaccurate when applied to my comments on HN about Dart.
DartVM never had a chance, I told 'em so and gave concrete reasons why it didn't. Worse, the leaked DASH memo was arrogant and wrong in declaring that JS "cannot be fixed by evolving the language". Anders Hejlsberg gently pushed back against that bogus assertion in 2012:
(Note that Mark Miller did not write this memo, he just accidentally posted it to a public Google Group thinking that group was private to Google employees.)
A lot of water under the bridge since 2010, and some of it had good effects for Dart users for sure, even with Dart now only a compile-to-JS language. But a lot was wasted. Dart could have used bignums (Dart `int` support) in ES6, for example, and this would have helped JS users too. The lack of it is a direct cost of focusing on DartVM at the expense of dart2js; see
You are right that I disliked the stinky politics and enormous question-begging on display in the DASH memo. (That's me disliking a set of bad arguments, not me disliking Dart.) It was a statement of intent, to fund a project because some people of note wanted to do that project, even if it wouldn't work cross-browser, and even if it imposed high opportunity cost to JS both in Chrome (the whole V8 team had to be reconstituted in Munich) and in Ecma TC39 (no one showed up to argue for better cross-compiling support in general).
WebAssembly should grow dynamic language support for Dart and languages like it, but that's years out. In the mean time, only JS as compile-from-Dart target is available. ES6 could have used the help.
It's fine for well-funded entities to waste money on boondoggles (well, not really, but I was not a shareholder, and Google is free to "experiment" for any reason it pleases). But I'm not obligated to praise a bogus justification when it leaks, or honor the two-faced way that JS was dealt with in the memo, and evident from the direct and opportunity costs of DartVM.
> That's me disliking a set of bad arguments, not me disliking Dart.
I stand corrected. Yes, I've read all the memos and watched all the videos, including this one when I knew Dart wasn't going to make it into Chrome for the first time. I knew it by Blink engineering lead Darin Fischer's reaction when asked about Dart [https://www.youtube.com/watch?v=TlJob8K_OwE at 17:25] To me it looked like he laughed and sort of scoffed, then he and another member talked Dart down. Maybe it is a failing of mine to look at emotional content when considering issues, but doing so sometimes imparts useful information.
At one point I was passionate about Dart because I thought it hit the sweet spot between JavaScript and Java applets in the browser with optional typing and generics. It turns out TypeScript hit that spot well enough and Anders was right about that.
I understand your frustrations about opportunity costs and lost effort that could have gone into JavaScript, but there is another possibility -- and this is just my opinion, which I voiced at the time -- that the Dart team was more focused on Dart on the server as a Java replacement. This was at a time when Oracle's lawsuit with Google over the Java interfaces was a big question. I thought Dart might be a plan B on the server and why Dart2js was not getting the attention I thought it deserved.
The JavaScript output on the client was unreadable, very large and much of the disdain for Dart from JavaScript devs was for this reason (17000 lines for a "hello world" if I recall correctly - I am not a systems guy but isn't most of that the DartVM translated to JS. Couldn't it be compiled to asm.js and loaded ahead of time if so desired?)
I think we agree on most of this and I apologize. It wasn't my intention to offend you. Dart still has a chance if they can get the translator to ES6 to work, and I don't see why not, so I hope to use Dart when and where it makes sense.
Thanks for the reply and apols -- no hard feelings.
At least the new Dart compiler generates nice JS, and the future efforts on Dart and JS look more aligned. We still don't have a bignum champion in TC39, but we do have great SIMD championing from John McCutchan (who started it) and Daniel Ehrenberg of Google; Dan Gohman of Mozilla; Peter Jensen, et al., of Intel; and others at Microsoft whose names I'm not remembering. This leads to value types as an extension mechanism, so we should get bignums sooner or later.
On whether DartVM was justified as a hedge against Java going away on Google, I've heard that too, but both for Java on the Google server side and for Android Java, I have never seen any evidence to support this notion. I'd want to see an efficient AOT compiler from Java classfiles to Dart, for example. Another example: some convincing work on library/framework parity on the server side to go along with Dart's (very nice) DOM and client side libraries.
Perhaps such work was kept behind firewalls. If instead it was just a case of saying "oh, we may be able to use DartVM if things go south with Oracle", that velleity hardly counts as an intentional, operational Java replacement strategy.
You might be interested in ES6’s arrow functions, which change the behaviour of this to something you might approve of (you didn’t specify how you thought it was broken):
Just because you don't understand the JavaScript this, doesn't mean it's broken. It behaves exactly the same way every time you use it... It refers to the object that called the function (unless, of course you or someone else overrode it).
Lots of languages, notably including Dart, compile to JS now. WebAssembly will support even more with high efficiency in the next year or two -- not in "20+ yrs".
> IMO, the choice of IndexedDB over WebSQL set the Web back 20 years.
Yep. I recognise that this may not have been a winnable fight, but I absolutely judge the people who were on the other side.
WebSQL was a much better tech than IndexedDB. Was the dependence on Sqlite problematic? Sure. But Mozilla had the resources to make a pretty good try at fixing it; instead they refused to even implement it and gave us the relatively terrible IndexedDB instead. Which, in turn, Apple has refused to implement[1], and now here we are. Thanks Moz[2].
(I'm less concerned about NaCL and Dart, because it's less clear to me that these were obviously superior technologies that obviously needed cross-browser adaption. You're certainly right that the pattern is suggestive though.)
[1]: Yeah, I know, they claim to have implemented it. Anyone who's tried to use their implementation will recognise this claim as a subtle joke. On us.
[2]: Their blog post justifying themselves[3] has not aged well. I especially love the bit where they say IndexedDB is better than WebSQL because it has better "developer aesthetics", as if anyone is actually casually coding against IndexedDB without using some sort of wrapper or compatibility layer. Or as if anyone actually likes the IndexedDB syntax and API.
How would you fix WebSQL? Writing a from-scratch implementation of SQLite seems like the only option, and I don't think Mozilla had the resources for that at the time.
I agree the situation sucks, but I'm not sure how to fix it even today.
Like I said, I'm not sure this was a winnable fight. And yes, writing a good DB implementation from scratch is really, really hard. But...
First, keep in mind that lot of this decision was political; if Mozilla had lobbied for it a lot of fudging could have been done. Instead Mozilla made sure that a strict reading of the rules was used by which, yes, WebSQL clearly failed.
And no, Mozilla probably didn't have the resources to implement SQLite from scratch, but:
1. They could have worked with others. Apple, quite clearly, was much more invested in WebSQL than IndexedDB. Could they have contributed to a join effort? We'll never know.
2. In particular, the rule about needing two seperate implementations is good, but it could have been fudged here; a bigger problem was the lack of a spec beyond "whatever Sqlite does". Did Mozilla have the resources to clearly specify how a reference implementation should work, even if the only actual implementation remained Sqlite? Maybe. Would that have been enough? Arguably.
3. In the event, IndexedDB was not a real replacement for WebSQL; at most it was an important tool that could be used to build one, some day; a process that is still ongoing (eg, with PouchDB) and has no real end in site. Even if we lacked the resources to really bring WebSQL up to par and re-implement Sqlite from scratch, we apparently lack the resources to bring IndexedDB up to par too. If we're doomed to spend years struggling with broken implementations and poor browser support either way, what did we gain with IndexedDB?
Like I said, I don't know that there was a good solution to this. But I feel like Mozilla helped ensure we got a bad one.
I guess I just disagree that it would have been good for Mozilla to fudge the standardization rules.
The rule of having multiple implementations is an important one.
And it might have been possible - surely Google and Microsoft, who supported IndexedDB, had the resource to write an alternative implementation. I don't know the history enough to know why they didn't.
I think I'm more cynical about the process than you are. From my point of view, the process has been intensely political from day one, with rules honoured mainly in the breach.
Has some very good details. And it's certainly funny to see what was said during the discussion with how things turned out in practice.
Edit: I'd sum it up as "Google and Apple argue for a solution that will work on mobile; Mozilla and Oracle don't care about mobile, are weirdly obsessed with the idea that developers hate SQL, and use political manoeuvring to win the fight". (Oracle's role in this seems especially odd, but perhaps they had some longer term strategy in mind.) In any case, in retrospect ignoring mobile was a bad idea, and ditching SQL seems to have had no real benefit.
That's a very misleading summary. Mozilla is rather clear that they don't want to spec on a specific version of SQLite. The one thing that is weird is Mozilla saying that developers want "anything but SQL", which sounds like BS. But even if they were in agreement that SQL was great, the simple fact that there's no independent implementations of SQLite 3.6.whatever's SQL dialect is good enough reason to not make it a standard.
It does show the total need for a fast, JITable intermediate language, and the silliness in not having one from the start, or at least long, long ago.
> Mozilla is rather clear that they don't want to spec on a specific version of SQLite
Not entirely true either. From the link:
> Hixie has said before he’s willing to fully spec the SQL dialect used by [WebSQL]. But since Mozilla categorically refuses to implement the
spec (apparently regardless of whether the SQL dialect is specified), he doesn’t want to put in the work since it would be a comparatively
poor use of time.
It's clear in the email thread that the "spec" world just be codifying exactly what that version of SQLite did. It's not likely they'd pick an existing SQL dialect that's compatible with SQLite, or they'd be essentially limited to that version of SQLite. Result is that you'd end up with the same problem and things would not really be compatible.
Even in that article, the a dev says he's queried the SQLite version in order to detect which exact FT options are available.
The argument for it is basically "eh but it's handy", ignoring the idea of the Web.
I didn't feel the need; it just brings the discussion back to my earlier comment upthread.
If you don't want to just use Sqlite (understandable), and you don't want to write something that is as good as Sqlite (also understandable), then you're going to have a crap database implementation. There's just not a lot of other options there. Jonas' comment just reiterates the lack of choices.
But given the three bad choices, the question does arise: Was IndexedDB really the best of a bad lot? In 2009, a lot of very optimistic things were said about IndexedDB performance, adoption, usage on mobile, developer acceptance. It's been 6 years, and I think it's safe to say that IndexedDB hasn't lived up to anyone's hopes.
Clearly it was dumb for people at Mozilla to take a bullet for Microsoft. But no matter -- I'm curious why you can't see past that and (also) hold Microsoft to account for rejecting WebSQL.
One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that.
When there is just a single codebase, even if it is open source, it isn't a standard. Now, not everything needs to be a standard, but on the web standardization is a big part of why it is so successful.
One example of why a single codebase is bad: Imagine that SQLite version X is the implementation of WebSQL, which all browsers must use. SQLite development is of course continuing, fixing security issues and making it faster, etc. Will browsers just keep using SQLite past version X? What if the SQLite community takes SQLite in a direction that isn't optimal for web browsers? Perhaps web browsers will fork it. What if browsers end up not agreeing on the fork, and some use the original project, and others use the fork - or there are multiple forks?
All of that makes it very risky that compatibility issues will appear between browsers. Having a properly specced standard, with multiple compatible implementations, is so far the best way that we have found that can prevent such things.
More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.
I agree. And neither is WebSQL. I was speaking to the "approach to Web Standards", not actual Web Standards. My point being that Moz used (IMO) conjecture and FUD to roadblock those technologies. No attempt on their part to experiment with those technologies and prove their value. In return, we've got instead IndexedDB over WebSQL (which many devs choose to wrap), asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for), and ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS.
I don't think it's FUD at all. asm.js is legitimately a more practical approach to the problem than NaCl, which is tied to the Pepper API. You can go back to the conversations on the plugin-futures mailing list in which everybody except Google was in agreement as to what should have been done instead of PPAPI; Google went with PPAPI anyway, sealing NaCl's fate with regards to adoption. Nowadays, we have Web Assembly, which Google and Mozilla are both working on, and which combines the best of both worlds. As for ES language improvements, I don't see at all how extending the existing language constitutes "bloat" over having two incompatible VMs. It's strictly less bloat, because you don't throw more VMs into the browser.
To add another example, I normally do JS using Node and there (and also in IE) you have a very useful function: setImmediate.
A few days ago, when doing some client-side JS I wanted to use it and I saw that it is not part of a standard, not only that, it has actually been REJECTED. It's really sad to see the development of the language crippled for a reason that basically boils down to "No, because it was proposed by Microsoft".
Technically for profit, but with no external shareholders to bow to, no stock options for employees, etc.
Don't be misguided by the administrative setup. Mozilla is earning money from partnerships, but the company goals are driven by the not-for-profit mission statement. It takes resources to stay in the game...
Agreed. The only time I've used Firefox's customize mode is to remove crap they keep insisting on putting in my toolbar. I think it's pretty clear that the only reason Mozilla is complaining about this is because they think it will hurt their bottom line.
