10-15 years ago I would agree, but now I feel I must add something to that sentence: any browser that supports the standards before they became Google-ified because it is churning the standards so much that its weapon of monopoly is effectively change --- Firefox can barely keep up, and Microsoft already surrendered.
What we really need to get rid of is the idea that websites are designed to work only on the very latest version of Google's browser or one derived from it. Text-and-images "formatted document" pages should absolutely not require JS just to show their content, and readable with a text-based browser too.
Even webapps, which are more sensitive to browser environments due to their heavy use of JS, should not stop working on an older browser just because a newer version appeared --- after all, it did work before. I really don't understand the rabid trendchasing and forced deprecation the webdev community seems to love so much. All I see are webapps getting slower and ceasing to work, namely doing almost the same thing they could be doing decades ago.
It took _years_ for XMLHTTPRequest to become a dominant influence on site design. Google can push new standard changes in fraction of the time because _their services demand it_.
> Even webapps, which are more sensitive to browser environments due to their heavy use of JS, should not stop working on an older browser just because a newer version appeared
Those are vendor-bound apps.
They're Google Chrome Apps, not web apps.
At this point, what can we do?
Like the archiving standard for PDF. Perhaps a formalized version of “graceful degradation” if you will with a known set of target.
One target could be a self contained, script-less, bundle f.ex.
Also it's orthogonal with JS usage, anecdotically I mainly work on JS heavy websites and don't use Chrome.
Just shut it down and restart it every couple of days because it’s memory usage isn’t as tight.
Fellow web-dev here, using Firefox (the one that comes with Ubuntu) as main driver. And I'd like to know if the Developer Editiion offers any benefits over the stable one, for webdevelopment.
[1] https://developer.mozilla.org/en-US/docs/Tools/Network_Monit...'
[1] https://developer.mozilla.org/en-US/docs/Tools/Responsive_De...
Rather novel weapon. This won't work, rapid change will just leave the large base of web developers behind. Tutorials and practices based on the Old Way hang around for decades.
Google putting out a standard is only going to help them if it is (a) in demand by web devs and (b) competitive with the old way of doing things.
I don't particularly like web apps, but they are a new field and rapid change in the standards is not really a sign of monopoly.
You can try and model things on the idea of rational experienced senior devs all making tech decisions based purely on hard evidence-based demonstrations of material benefit of new tech over old tech, but reality is much softer than that.
Another factor is that Google's hold over SEO allows them to drive change through SEO requirements. E.g. there's always been a lot of overlap between new tech introduced and Chrome and requirements for Google search indexing, and that stands to increase with things like Core Web Vitals,
> rapid change in the standards is not really a sign of monopoly
Your statement here seems to be just picked from the ether and not actually based on anything in reality: there's no reason rapid change cannot be associated with monopoly.
There are many differences between how Google is approaching tech and how Microsoft did in the late 90s / early 00s but the its worth noting that second E in their infamous Embrace, Extend, Extinguish strategy most certainly involves rapid change in standards. This is hardly the only example, but it's notable I didn't even have to pick a different industry to find one.
However web dev practice has been driven by Facebook and its quasi-functional programming advocates for at least 5 years now (Redux/React). There's a whole generation of Web Devs that don't know that DOM Event handlers can be objects that bear the handleEvent interface because React prohibits that application for example, but that's a whole world of memory efficient async handling rather than generating throwaway functions for ever little thing
Almost all if they're abusing their search monopoly to force their preferred web "standards" on the rest of us?
Unfortunately, independence ends with the choice between WebKit (QtWebKit) or Blink (QtWebEngine), albeit with a faithful Opera 12-like interface that's less resource hungry than Vivaldi. Otter is still in development and it shows in some rough spots and occasional crashes.
For example, after switching the preferred engine in about:config, it's even possible to leave Otter in a transitional state, having one tab load a web page in WebKit, and another in Blink, in the same running application.
Doesn't change the fact that it's been deprecated/removed upstream, though, unfortunately.
Who outside of Apple is using WebKit at this point? And how often do the tarballs drop?
Gnome/GTK, at least. The one bundled with Gnome (previously called Epiphany) still uses it. I was going to say Midori, but apparently it's recently-ish switched to Electron, which is understandable, but a little disappointing.
There are other niche browsers using WebKitGTK, but with the loss of Midori (?) and Qt's WebKit interface its definitely got a really small presence now.
> And how often do the tarballs drop?
Unlike most open source projects inside Apple, WebKit is developed basically in the open, with a dedicated website at https://webkit.org/ and an SVN repo at https://svn.webkit.org/repository/webkit/. They also link directly to the WebKitGTK project, and provide instructions for building for/on Linux (and Windows).
It's kind of a shame it's not more widely used -- I understand why most people so inclined would prefer Gecko/Firefox, but there may come a time when the only valid choices are a rendering engine backed by Google's dollars, or one by Apple's dollars. And unlike Mozilla, which is still mostly relying on Google's dollars, Apple has a vested financial interest in keeping a separate and at least adequate web stack.
Edit: Worth mentioning one problem with WebKitGTK adoption in linux has been API deprecation. I haven't done any dev work with it, but I know a lot of projects just gave up after the WebKit -> WebKit2 port, and GTK itself can be a PITA. The tooling outside Darwin/OS X is more cumbersome, too.
JavaScriptCore is easier to embed/better documented than SpiderMonkey, though (IMO). And it can even run headless, although getting it to build headless can be, uh, finicky...
https://www.phoronix.com/scan.php?page=news_item&px=QtWebKit...
It's essentially a continuation of the Mozilla Suite (formerly Netscape). However they're falling behind on Gecko integration, with the latest version still on Gecko 60 (2018) with backports.
The reality is that Mozilla doesn't focus on embedded applications of Gecko besides Firefox (even Thunderbird is sidelined these days). Projects that are essentially third-party, like SeaMonkey, really have no visibility at all. This is the reason why the Chromium Blink engine has become so widespread, especially when it's been nicely packaged up by the commercially-backed Qt project.
There's PaleMoon, which is a fork, and there's SeaMonkey, although the latest version is based on Firefox 60.8 (May 2018), so I guess that's more of a fork than "using the Gecko engine" too? Also the UI is a bit too 1999-esque even for my tastes.
So I guess it's just hard to re-use Gecko? Using QtWebEngine (or QtWebKit before that) is very easy. No really, it's 20 minutes and you have a basic browser. I built a basic "vim-like" browser in the style of Qutebrowser in a day with PyQt (missing a lot of UI stuff and polish, obviously) and I'm not even very experienced in Qt/PyQt (or GUI programming in general).
Say what you will about Blink/Google, but the easy with which you can build a browser on top of it has spawned a plethora of browsers, ranging from Edge and Vivaldi, to all sorts of more niche ones like Otter and Qutebrowser, and many more.
Half of Vietnam is using Cốc Cốc. Yandex Browser is fairly popular in Russia, UC Browser is popular in China (or rather was, since it was banned) and some other Asian countries.
There's no reason at least some of these couldn't have been a Gecko-based browser.
Yeah, for smaller projects with only a handful of people behind them, WebKit (via WebKitGTK) or Chromium (via QtWebEngine, Electron, Chromium Embedded Framework) are pretty much the only choices there are. The only exception maybe being Pale Moon.
For browsers which are based directly on the Chromium codebase without being supported by Google, there are definitely many more resources needed - I don't see a particular reason why those couldn't be based on Firefox either. From what I see in QtWebEngine, keeping up with Chromium isn't exactly easy - IIRC they said they need about a person-month to catch up with a new Chromium release, usually with millions of changed lines.
I was hoping for Servo to fill that embedding usecase gap, but it looks like that's been mostly abandoned by Mozilla nowadays. My only other hope is GeckoView: https://mozilla.github.io/geckoview/ - I know at least the people behind Tridactyl would love to see it ported to x86_64: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64
Not sure where Firefox/gecko is now, but pulling the rendering apart from the UI and improving it to be usable by other UIs, projects, would help get this done.
Otter-Browser uses QtWebKit.
So it's still another entry using the "one" technology, WebKit (which Blink is a fork of as well).
Otter-Browser doesn't change anything at all about the erosion of standards. The only WebKit-independent engine we have still is Firefox Gecko.
If someone says "I use Chrome" what does than mean to you?
Just curious.
Perhaps some websites do not make use of all the standards, thus browsers do not need support for all the standards for these websites to "work". For example, HN does not require a popular browser. In fact it can even be used without a browser. Why are so many "web devs" using HN but few to none of them can/will design similarly fast websites. That's a rhetorical question. (That means everyone already knows the answer.) Do "web devs" actually use the sites they design. Why would "web devs" use HN when it does not represent their own taste in websites. What does that mean.
If someone says "I use Chrome" what does than mean to you?
Just curious.
Perhaps some websites do not make use of all the standards, thus browsers do not need support for all the standards for these websites to "work". For example, HN does not require a popular browser. In fact it can even be used without a browser. Why are so many "web devs" using HN but few to none of them can/will design similarly fast and flexible websites. Do "web devs" actually use the sites they design. Why would "web devs" use HN when it does not represent their own taste in websites. What does that mean.
But in reality, most developers have very little agency over technical decisions. Sure, they're the ones actually building it and choosing the exact tools and frameworks, but they have almost 0 control of their own constraints.
Metaphorically, companies decide they only want to use nails because they're cheaper. Even if screws would be better. The conversation inevitably turns into frustration with developers' overuse of hammers.
[0]: I get that we say "developers" to also include publishers/etc, but the term often morphs back into blaming the "technical implementers" on the team.
I like the name.
It lends it self to saying "I use the Otter browser" which is not just a great pun but the pun on 'other' defines what Otter is, the "other" browser. The web needs independent browsers. We need to get rid of the idea that websites are designed to work on any one technology. They should work on any browser that supports the standards.