A lot changed in the last ten years. It may not seem like it because most of those changes were refinements on things we already had at the time. We've just been in a long period of revisions. New programming tools, new social networks, new [insert thing we've had since the '90s]. The late '90s and first half of the '00s were full of radical changes, so it seems less significant in context.
We're probably on the brink of another radical upheaval like the '90s. There's lots of money flowing around, lots of amazing and well-refined tools, and all the low hanging fruit is more or less captured. No one's getting rich on "x as a service" anymore. People will have to really change something to capture the next huge payday, and the first few will set off a cascade of changed expectations.
It has been like that C. S. Lewis quote - day by day, it felt like nothing big has changed, but looking back, everything is different.
I guess I can see this seeming reasonable in the early 1940s, but it was fully crazy even before Tim built this awful Heath Robinson hypertext system we're using, let alone this century. The Network is not like cars, or pants, it's not a passing fad that societies grow bored of, it's at the heart of what we are as people, it will outlive us all.
I remember trying to explain a lot of this stuff in the early 1990s when I was a teenager - to my parents and being bewildered by how little they understood what had already happened and what would inevitably happen next. It was really like I'm stood on a beach, there has been a distant rumble and the tide is going out very fast, and I'm saying "Inland. Mum, Dad, right now. Don't stop to pick up towels and stare at the horizon, we must hurry inland or we will drown" and they don't get it at all.
[But mostly I just came here to practice using an em dash correctly…]
Or put in a different way, if the browser changes in 2007 are "ancient", how would you describe the ones that happened 10 years before that? Prehistoric? Jurassic?
Well it's not like there aren't any bugs in the specs. And whether there are bugs in the code or the specification, it's the same process for fixing them : politics :)
Historically the process for building web-platform features has been to write a spec and then assume that implementations of the spec would reach compatibility in an ad-hoc manner by patching until sites worked. The big innovation of the last decade — still controversial to some — was the idea that it's OK to adjust the specs themselves when implementations have converged on some other behaviour or when the spec is otherwise wrong. The goal for the future is to use the same engineering discipline that you would use for developing software to developing the platform itself. In particular the objective is:
* Every change to a spec that influences browser behaviour must be accompanied by a corresponding test case. * Every change to a browser that affects a cross-platform feature that isn't already adequetely tested must be accompanied by cross-browser test cases. * The results of those tests must be visible to browser vendors in a way that makes it easy to identify the higest value bugfixes (e.g. cases where N-1 browsers agree and one is different, or cases where a spec change makes previously correct behaviour — which may not have shipped yet, but just be enabled on nightly builds or behing a flag — wrong).
Apart from the work of actually writing the test, achieving those goals involves a lot of infrastrucutre work to ensure that the cross-browser tests are well integrated into the development cycle of each browser and are able to cover as many scenarios as possible (testing often involves manipulating the browser in a way that is not exposed to normal web content). Despite the large scope of the project, I think it's agreed that modernising the way the platform is developed, and prioritising interoperability at all stages of spec and browser development is essential to avoiding existential threats to the open web in the long term. Certainly Mozilla put a lot of resources into post-hoc fixes for site-compatibility issues, and whilst there will probably always be some bugs that slip through, it will be much more efficient to catch those problems up-front before they ship to end users.
I sadly don't have data to backc this up, but I'm pretty sure we're already seeing the effects of this effort, with recent, complex, features shipping with fewer cross-browser issues that we would have predicted five years ago.
There was a post from an Opera insider that I can't find but it was basically this: the web's complexity was evolving faster than the Opera team could maintain their proprietary Presto rendering engine.
Switching away from Presto and building on WebKit was a basic matter of survival. Yes, they still became irrelevant but they would have also stayed irrelevant with their Presto engine.
I agree with their assessment because around 2009, I started encountering more and more web pages that broke Opera. The Opera forums had more and more complaints from users reporting broken web pages. The Presto engine was becoming a liability.
It was a vicious feedback loop because web authors wouldn't bother to test their sites with Opera ... which led to more user frustrations. I had to switch to Chrome to get a usable web surfing experience back. I originally paid for Opera because it had the fastest rendering engine which was very helpful for slow dialup connections. As Presto started falling further behind, that speed advantage was negated.
Opera did try to some interesting features such as "Unite" which -- if you squint a certain way -- was a form of p2p decentralization. Yes, it's interesting to have a built-in web server in the browser but not enough people cared about it.
The author's predictions for Firefox's Gecko engine meeting the same irrelevant fate as Presto didn't happen because unlike Opera, Mozilla from 2004-2014 got massive funding from Google. Mozilla could afford to keep programmers enhancing the Gecko engine. Opera couldn't do the same with Presto.
There are always options. Opera could have doubled-down on Presto; putting more people on the core team, and focussing efforts to keep up with, and surpass, WebKit/Gecko. After all, that's basically the option that Mozilla took, which has resulted in Firefox Quantum. Would that have worked? It's hard to say. I would guess not, but I'm not sure the alternative really did either. Maybe Opera was already too far down the web-compat death spiral to engineer a way out. I don't know of a long-term bet like Rust that could have come good at the right time.
Certainly the top-level culture of the organisations was different; Opera's leadership were very concerned with maintaining/maximising the value of their shares, whereas Mozilla is more clearly driven by ideological goals around the success of the open web. Opera also had a (historically well justified) belief that they could do more with fewer engineers than other compaines. That seemed to work up to a point, but once the difference in resources became too great it was hard to change the approach.
Certainly one lesson is that it's hard, maybe impossible, to be a niche browser with a unique rendering engine. That is arguably a failing of the web, but nevertheless it's a strong indication that arguments that e.g. Mozilla should aim Firefox at small ideologically-driven markets are dangerous. One interpretation of the Opera history is that they were too focussed for too long on the subset of users who wanted a browser with lots of features and configuration possibilities. A product that suits those people might be actively offputting to other users, so inhibiting marketshare growth when faced with competition targetting simplicity and sane defaults.
Unite is a typical example of something that worked fine and disappear all the same. I haven't find any browser that surpass Opera 12 to this day. All the new "exciting stuff" are no use to me. I don't want to adapt to my browser, I want a browser that adapt to me.
Saying that, roc proposes porting XUL and XPCOM which are largely dead these days (the former by virtue of Firefox switching to WebExtensions). With browser.html for Servo being a thing, building Firefox’s UI in a way that it would work in WebKit is more possible than ever.
A few years hence ease of producing MD5 collisions might render moot anything that you had to say.
Thank god they eventually “saw the light” and they’re now back on track.
You also totally misunderstand the goal pursued with FxOS, which had nothing to do with "run from their own browser and tech". If anything, the current work to remove XUL and xpcom puts Firefox closer to how FxOS was built, not further away. At the time some employees even build a new desktop browser around the same tech (not the failed Tofino experiment), that was outperforming Firefox because it had a lot of the "new hotness" like e10s and web extensions. Guess what, the desktop team ignored it, only to do the same thing later.
Mozilla is not back on track at all, they are still playing catch up on the desktop market which is not growing much and totally irrelevant on mobile.
But they have enough money to last years, in a weird way of "to rich to fail".
FxOS embraced web technologies, but didn't embrace the browser. I think Mozilla is still having a hard time embracing the browser, though at least now the will is there.
Who at Mozilla ever talks about hypermedia? About link text? About navigation? About bookmarks? FxOS was a demonstration of how hollowed-out the philosophy of the browser had become at Mozilla. It used web technologies to faithfully clone non-web UI and OS organization. It would be like reimplementing JavaScript in JavaScript: an interesting intellectual pursuit, but completely useless.
> If anything, the current work to remove XUL and xpcom puts Firefox closer to how FxOS was built, not further away.
Technically yes, but the motivation is different: this is work to make Firefox better, not to make a better-thing-that-is-not-Firefox.
> At the time some employees even build a new desktop browser around the same tech (not the failed Tofino experiment), that was outperforming Firefox because it had a lot of the "new hotness" like e10s and web extensions. Guess what, the desktop team ignored it, only to do the same thing later.
The Firefox Desktop team was too small to pursue much of anything. It was like a dozen people maintaining the Firefox frontend. Progress couldn't happen until the organization was aligned to actually support Firefox.
> they are still playing catch up on the desktop market
It's not the sort of wave you turn in a month. 57 is a big release, give it time. It had a massive surge of good press, which is a good sign. If they can come up with developer tools that can beat Chrome at something, they will see numbers go up.
> totally irrelevant on mobile.
They are making inroads on Android, which is the only market they will ever play into. iOS will only be cracked open by legal coercion. Anything else is wishful thinking.
> But they have enough money to last years
Mozilla is not just a company, it's basically a public institution. Their role is to champion a view of the web as an open utility, not to be the most popular widget maker. They don't need bazillions of money to do that.
While I appreciate that we still have the independent Firefox and its brand new Quantum engine, sometimes I feel like the Konqueror/KHTML team does not receive the appropriate tribute for laying the foundation for the dominant KHTML/Webkit/Blink engine.
Who would win then? Google's money and marketing power, or Mozilla's independence, trustworthiness and being the renderer's creator?
ec06b3461cf0eaf3d3e4d7a2e429bddb
$ curl -s https://raw.githubusercontent.com/rocallahan/blog-archive/master/hashed-blog1.txt | md5
9ba0c5cba20cff553500f034f58d5bb7
that said, the others check out, so i'm sure it's harmless.
I wondered if anyone would check :-).
I'm not sure what the problem is with the first post. It's been a long time. You'll have to take my word for it that the first post is the right text :-).completely ignores the fact that google effectively took over the project, killing old features it didn't like and preventing any new contribution from making it to main line unless they fit their plan.
Have they considered rewriting it in R... oh, hang on.