I think the only way new browsers are going to succeed in the future is if they adopt some major new technology that the mainstream browsers either will never use, or will wait many years until they consider it. Perhaps something like IPFS or some blockchain technology, or anything like that, that is proven to work well but the mainstream browsers still think it's too new and risky, or perhaps just don't want to piss of the MPAA, which by the way, is now a member of the W3C.
The new browsers will need to allow for significant new possibilities, for users to want to adopt them.
The code itself works very well. Mason, founder of Luakit and most generous contributor, got hit by a bus so new maintainership roles have yet to get filled by existing and new users and developers. All current development takes place outside of "central" repo, and it needs organizing and compiling. Once this takes place, development and merge requests can continue full course.
It's right there on your qutebrowser link, dwb is first on the "Similar Projects" list (Scroll down) their "Unmaintained" comment leads to the reddit thread you mention, mind you that thread is 1 year old and the user/post is deleted: https://www.reddit.com/r/linux/comments/2huqbc/dwb_abandoned...
Ah, I see. Either way, I was eager to switch at the time as webkitgtk had a bad bug in it that would cause dwb to insta-crash on loading a page about once an hour and which wasn't getting fixed. Qutebrowser is based on Qtwebkit and didn't have the same issue, so I jumped ship pretty early in its development.
Frankly i have taken to consider all webkit browsers the same, meaning that the web is heading towards another monoculture akin to what we had when IE was what everyone developed for.
For one, WebKit is now forked, into WebKit and Blink. Both of them are rapidly diverging. And there are still enough people using Gecko and Trident (and now EdgeHTML) that you can't just target the intersection of WebKit and Blink and still have any reasonable kind of coverage.
For another, I think you fail to understand just how dominant and stagnant the browser market had become when IE was dominant. Not only one browser, but one version of one browser, had over 90% market share, and in controlled environments like corporate networks, effectively 100%. In that kind of environment, it was completely reasonable to just target that one browser.
Today, even if you add up all of the WebKit and Blink browsers based on the most generous market share counts, you won't break 70% market share, and there are even still some statistics that have IE/Trident at over 50% market share. So unless you're targeting a very specific market, like iPhone users (where yes, WebKit's share is 100% due to Apple's monopoly), it's very hard to find any demographic in which there is such a strong dominance as IE had back in the day.
Additionally, browsers and engines are actually being released at regular intervals these days, with new features and bugfixes. Firefox/Gecko and Chrome/Blink are on rolling 6 week release cycles, meaning that there's very little lag to getting new features and fixes out. Safari/WebKit is released less often, but once every year or two. There were 5 years between the release of IE 6 and IE 7, and IE 7 didn't even pass Acid2, it would be another couple of years until IE 8 did. That extremely long period of time in which one version of one engine was so dominant led to an awful lot of sites designing themselves exactly around the bugs and quirks of that one engine.
Couple that with the fact that standards committees are actually working on features that people want, and are making real progress. XHTML stagnated the standards process for a long time, working on a backwards-incompatible specification that did a lot of architecture astronautics on representing documents, when what people needed were backwards-compatible enhancements that supported web applications so they could roll things out incrementally as support became good enough. CSS got a bit mired in CSS 2, but CSS 2.1 allowed them to slim down the specification and get out something working, while CSS 3 allowed them to work on individual features separately, and thus be able to make progress without having to wait for everything in the world to be ready. Another big reason for IE's dominance was that it had proprietary features, like filters and ActiveX and webfont support, and there were no standards that covered similar ground. Now we have HTML5, a plethora of new APIs for interacting with the browser, a substantial number of CSS enhancements, highly competitive JavaScript engines that are capable of running full 3D engines, and so on.
And finally, WebKit, Blink, and Gecko are all open source. People can be involved in helping find and fix bugs, implement new features, port them to new platforms and devices. A big problem with IE was that it was proprietary, and ran on one platform. You could build a desktop browser that ran on Windows with your own chrome around it, but that was about it. Now, you want to make some cool new device that needs web rendering support? You want to experiment with interesting new ways to present web content? You now have several high-quality, open source options to choose from, which have enough market share that most sites have done the compatibility work to make sure they are compatible.
Sorry for the wall of text; I just wanted to make sure that you understand the history, and how very different the present situation is than the one in which the IE 6 monoculture flourished. It can be a bit worrying how two engines with a common ancestor have such dominance on mobile, WebKit and Blink. It's also worrying that Apple's monopoly prevents people from installing browsers with more up-to-date engines on their phones; I think it's an abuse of their control of the platform. But even so, they don't have the kind of market dominance even on smartphones that Microsoft did on desktops back in the early 2000s, so while it's worrying, it's nowhere near as bad.
So, we'll be developing for 5 different target browser engines, 3 different operating systems, and about every viewport size imaginable for the foreseeable future.
>And there are still enough people using Gecko and Trident . . . that you can't just target the intersection of WebKit and Blink and still have any reasonable kind of coverage.
On the whole, that's an absolutely fantastic comment. But a few notes:
> So unless you're targeting a very specific market, like iPhone users (where yes, WebKit's share is 100% due to Apple's monopoly), it's very hard to find any demographic in which there is such a strong dominance as IE had back in the day.
As you hint towards later in your own post, WebKit/Blink are in many markets there on mobile/tablet: in Europe, WebkIt/Blink are over 90%. For many of my customers, they could make a quite sensible business decision to not support other browsers with the same level of testing. This still causes problems—we have Edge implementing large numbers of WebKit prefixed properties, Opera abandoning Presto in large part due to the WebKit domination of mobile (where, at the time, bug compatibility was necessary on several major sites), leaving Firefox as the last hold-out from supporting WebKit prefixes (and if they wish to make inroads on mobile, they'll have to).
> CSS got a bit mired in CSS 2, but CSS 2.1 allowed them to slim down the specification and get out something working, while CSS 3 allowed them to work on individual features separately, and thus be able to make progress without having to wait for everything in the world to be ready.
I'm relative certain CSS 2.1 is actually longer: it defines much of what's in CSS 2 in far more detail, with much less left undefined and fewer contradictions. What little that was dropped was dropped because it didn't meet the modern (post-2003 or so) requirements for specs to advance to REC at the W3C, namely the requirement for two interoperable implementations of each feature (technically, requirements to advance beyond Candidate Recommendation to Proposed Recommendation, whereupon the Members of the W3C vote (one vote per member) and the Director has a final say, thereafter being published as a Recommendation).
CSS 2.1 laid a lot of groundwork that's been vital for more recent modules: without a clear definition of many of the underlying layout primitives in CSS 2.1, it would be hard to define the new features in reasonable detail. That's not to say CSS 2.1 is perfect—there's work happening on CSS 2.2, primarily just integrating the current errata, and the test suite could certainly be better (Mozilla Research are paying me to work on that in the coming months, as Servo doesn't have the user base that would show many of the site compatibility bugs that arise as a result of their bugs, leaving them disproportionately reliant upon the test suite).
> Now, you want to make some cool new device that needs web rendering support? You want to experiment with interesting new ways to present web content? You now have several high-quality, open source options to choose from, which have enough market share that most sites have done the compatibility work to make sure they are compatible.
A lot of that depends on how "standard" your device is—if you're running Android, it's "relatively" straight forward. (I think Opera's recent rewrite of their browser, basing it on top of the Chromium Content API, shows that even implementing the UI is hardly a small effort.) If you're running everything statically linked, using DirectFB to write to screen (this is how many embedded browsers work), it is substantially more work, especially if you are concerned with minimising binary size. I think it's easy to underestimate how much work is involved in porting the open-source browsers to new platforms, yet alone keeping them up to date and providing security fixes (which given the short support period of each release, depends upon the former).
I was mostly responding on the basis of desktop browsers, since most of the rest of this thread has been about desktop browsers. You're right, on mobile the WebKit/Blink duopoly, with the shared code base that does mean that they are closer on feature and bug parity, is pretty problematic, but even there I'd say we're in better shape than the early 2000s IE monopoly.
> Mozilla Research are paying me to work on that in the coming months, as Servo doesn't have the user base that would show many of the site compatibility bugs that arise as a result of their bugs, leaving them disproportionately reliant upon the test suite
Nice, that sounds like it'll be quite useful. I am eagerly anticipating being able to actually use a browser based on Servo day-to-day. There's quite some ways to go, but it's great how much progress its made so far.
Already I run into issues occasionally with mobile sites not working in Firefox for Mobile. Usually I just switch to the full version of sites and they work better, but I don't think Firefox is being tested.
I really like surf and its model, but it needs ad blocking. I was working on that a few months back, but got distracted by other projects. Incidentally, the AdBlock list format is…insane.
This, to me, feels like the vital flaw. If I were someone who wanted a browser with all the features of Presto-Opera, I'd be worried about development of it being abandoned again.
It doesn't even support CSS2 properly (e.g. paragraph justification, em, etc). And despite claims of being blazing fast, as an user my experience is that it is very slow for more complicated pages, whereas for websites that are almost just plain text and images it beats any WebKit/Gecko browser out there.
It's great for Googling when debugging your code or reading HN when compiling, other than that I'd stick with <your favorite browser>.
> And despite claims of being blazing fast, as an user my experience is that it is very slow for more complicated pages, whereas for websites that are almost just plain text and images it beats any WebKit/Gecko browser out there.
I downloaded it and tried it. Every page loads very slowly, even incredibly simple sites. Maybe it has a slow HTTP implementation?
Yet. The Git version seems to already have preliminary JavaScript integration, based on Duktape. There was also an earlier attempt in 2012-13, utilizing SpiderMonkey.
Ok, so that explains why many sites did not work. Almost nice, though, not to experience all that annoying/excessive javascript that is so prevalent these days. I just love that NetSurf homepage - nothing that moves, pops up, scrolls oddly etc.
NetSurf seems to support SSL to the extent that it connected to my site, which scores an A+ on the Qualsys SSL Labs test, without any issues.
On the other hand, I agree that not being able to hit Command-L to jump to the address bar as with every other graphical browser (as well as many other browser-like applications) just… doesn't feel right.
Any https website that I visit with netsurf, I get this empty warning: http://imgur.com/7bmDqnP ... but I used the version available in my repo, which is 2.9 .
While I applaud competition, I fear that more browsers will make it ever more difficult to develop working code that doesn't break at the next update. I guess the middle ground is that developers are supposed to follow the major browsers, while the small browsers have to follow them too. This could work in practice (I suppose users have gotten used to things breaking on the web), but somehow it still feels like a failure of the field of Software Engineering.
Most sites I tried were somewhat broken. But to my surprise my own website worked just perfectly (sans javascript powered comments and ads of course). And blazingly fast!
"I wouldn't be surprised that now that both of them [Firefox and Chrome] are too complex, in a few more years someone comes out with a browser that is simpler than both of them and is intended to replace them both."
So for those who don't know it, there's also Xombrero: https://opensource.conformal.com/wiki/xombrero
It's based on Webkit so it's more compatible with the "modern web" than dillo/netsurf.