Neither Chromium nor Firefox works correctly today. This may not be readily apparent to the casual web browser, but is clear to the professional web developer. There are myriad problems, road blocks, and speed bumps to developing websites, of all different sizes and shapes, from mountains to molehills.
The biggest problem, in my view as a web developer of 10 years, is CSS and the document flow. It is extremely complicated, and very difficult to shoehorn into doing what you actually want. As one example, consider how many different ways there are to position elements on screen:
- • float property
- • position property
- • display property (itself highly complicated)
These element styles override each other and interact in specific ways, and also with the display settings of the element's ancestors, descendants, and siblings. More often than your average professional web developer will admit, when you fix one thing you automatically break another, like you're trying to pull out all the pom poms in a pom pom pole but they're all connected to each other.
Consider how much easier it is to position elements on-screen in a system like OpenGL. You know the size that each element requires, and write simple algorithms to arrange them within the larger-than-necessary (or, heaven forbid, smaller-than-necessary) window. The key difference is that GL code is written in a Turing-complete language like C, while DOM elements are positioned using HTML and CSS, which are not Turing-complete, but rather total, with an enormous array of different display methods for you to choose from that does not, and cannot, cover the whole space of arrangements that you may want.
So-called "responsive design" does not equate to writing a website in such a way that it "breaks down" when displayed on mobile. The phrases "graceful degradation" and "progressive enhancement" are both misnomers, belying the difficulty of the task and the true amount of code duplication. More often than not, a mobile responsive website is really two websites, one displayed on mobile devices and one on desktop, by way of media queries. Oftentimes, web developers recognize the futility of coding a single website to look good in multiple arrangements flip-flopping between them based on screen size, and instead redirect to an "m." subdomain running a mobile-specific site.
HTML-only sites are lots of fun, but as soon as you begin to apply styling, you leave the world of semantic, declarative, fast, accessible documents, and enter the world of garish, gaudy, florid web applications that you run on users' browsers without their knowledge or permission.
New browsers are few and far between, in part due to the huge startup cost required to create one. The HTML standard alone is 20% longer than the C++ standard! In addition to HTML, browsers must be able to understand at least two other languages: CSS and Javascript, not to mention the upcoming language WebAssembly. While the task of implementing a web browser, like any large project, can be broken into components, to an extent, using Javascript engines such as V8 and Rhino, and rendering engines such as WebKit, Blaze, and Gecko, each of these is itself quite large, and building a new Javascript engine has its own startup cost. Basically, web applications have their own established, ingrained tooling that you use, and it can be very costly to repair or replace. As I said at the beginning, neither Chromium nor Firefox, the two browsers you're most likely to develop for, work correctly. At the time of this post, Firefox, though a wonderful effort, has an extremely slow Javascript debugger. Both browsers' tabs occasionally get themselves into faulty states, and have to be closed and new tabs opened, for you to continue working.
As the various browser standards continue to grow, with the release of HTML5, CSS3, ES6, and beyond, the task of implementing a web browser becomes even more difficult, and does so monotonically. There is no reverse: backwards compatibility has to be maintained. Until and unless CSS is extended to be Turing-complete in the context of element positioning, writing CSS will continue to be a futile exercise where styles must be changed back and fourth and back and fourth throughout the application any time the tiniest change is made, and browsers will have to implement an increasingly baroque set of rules.
The bloat of the specification implemented by browsers could be solved by adding features to CSS so that it becomes Turing-complete, and can express any kind of element positioning algorithm you may want, reusably, and maybe event succinctly. I don't believe this will be done; it appears that the CSS spec writers are either blind to its problems or just interested in "creating jobs" like Bjarne Stroustrup was when he invented C++. This is why I say the browser is dead. As time goes on, and the browser virtual machine gets increasingly complex, only a small number of browsers will support the websites that people write, because new ones cannot be built without a herculean effort. With little consumer choice, existing web browsers will start to suck - and already have.
