4 ms·

The relevant comment from Bugzilla thread > Nonetheless, I'd argue that it's a matter of PR among the subset of users most likely to champion Firefox. > When

by snaky 8y ago

The relevant comment from Bugzilla thread > Nonetheless, I'd argue that it's a matter of PR among the subset of users most likely to champion Firefox. > When the reading list functionality just vanished on me one day and I rushed to make a backup of reading-list.sqlite in case it got deleted later, it did not leave me with a very good impression of Mozilla. (rather than, for example, seeing that it had been migrated to a folder in the bookmarks store.) > (In fact, I'm currently working on an external utility, to be integrated via WebExtensions, to store all persistent state which I don't feel I can trust Firefox to preserve when 52 ESR drops away. This approach to retiring bookmark descriptions only leaves me feeling more justified in the view that I can't trust Mozilla with my data.)

StillBored 8y ago
Add to that rant the fact that for a while mozjs was the choice javascript engine for various projects that wanted a JS interpreter. Then one day they decided to literally break the API, every couple weeks, and its been going on for years. The language bindings aren't even the same now, and projects like gnome end up with these rather large patch sets every few months just to keep up.
- bzbarsky 8y ago
  mozjs was a pretty old codebase with some design decisions that made sense in the mid-90s but don't make sense now baked into the API. The API needed to change to support things like a generational garbage collector. The set of needed API changes was quite large. Now the project had two options: Make the changes incrementally or all at once. The incremental option would mean API changes with each release until all the changes got made. The all at once option would mean you'd need to do a complete rewrite of all the relevant mozjs code and all the relevant Firefox code all landing in a single release. Since the time needed for that rewrite was measured in years, that would mean maintaining a branch and dealing with all the merge conflicts from other ongoing work. In practice, it would have meant a much slower pace of web-facing JS feature development at best; more likely a complete stop to that. Given those choices, the JS team went for the incremental route. Yes, it was painful for API consumers who needed to be running against current versions. But in this case, I expect it was the right tradeoff. I should also note that V8 breaks API compat regularly, though not to the extent that SpiderMonkey had to, due to being designed 15 years later with many benefits of hindsight. [Disclosure: I work on Firefox, closely with the JS team but not on the JS team.]

by snaky 8y ago

StillBored 8y ago

Add to that rant the fact that for a while mozjs was the choice javascript engine for various projects that wanted a JS interpreter. Then one day they decided to literally break the API, every couple weeks, and its been going on for years. The language bindings aren't even the same now, and projects like gnome end up with these rather large patch sets every few months just to keep up.

bzbarsky 8y ago
mozjs was a pretty old codebase with some design decisions that made sense in the mid-90s but don't make sense now baked into the API. The API needed to change to support things like a generational garbage collector. The set of needed API changes was quite large. Now the project had two options: Make the changes incrementally or all at once. The incremental option would mean API changes with each release until all the changes got made. The all at once option would mean you'd need to do a complete rewrite of all the relevant mozjs code and all the relevant Firefox code all landing in a single release. Since the time needed for that rewrite was measured in years, that would mean maintaining a branch and dealing with all the merge conflicts from other ongoing work. In practice, it would have meant a much slower pace of web-facing JS feature development at best; more likely a complete stop to that. Given those choices, the JS team went for the incremental route. Yes, it was painful for API consumers who needed to be running against current versions. But in this case, I expect it was the right tradeoff. I should also note that V8 breaks API compat regularly, though not to the extent that SpiderMonkey had to, due to being designed 15 years later with many benefits of hindsight. [Disclosure: I work on Firefox, closely with the JS team but not on the JS team.]