4 ms·

I may be getting old, but why and how did we let web standards inflate to such an extent that only large corporations or organizations are able to build a compe

I may be getting old, but why and how did we let web standards inflate to such an extent that only large corporations or organizations are able to build a competitive browser from scratch? There's so much money funneled into browser development these days and the results aren't entirely satisfactory for end users (DRM, security issues) and website developers alike, perhaps it's time to start over with something less bloated.

FooBarWidget 11y ago
Because of momentum and backward compatibility. What you say may make sense from a purely technical point of view, but you are not considering that 99.999% of Internet users are average users. Without backward compatibility you have no way of winning. And with backward compatibility you have... the current mess of patches upon patches.
Silhouette 11y ago
For better or worse, the answer to your question is clear if you consider the range of functionality that users now expect to be provided by any serious browser. Browsers a few years ago had to render a page using HTML and CSS, supported some light scripting with JavaScript, allowed the inclusion of a small number of different image formats (primarily JPEG, PNG, GIF), and delegated any more serious interaction using plug-in technologies like Flash, Java, and ActiveX. Browsers today have to render a page using somewhat larger versions of HTML and CSS, provide a professional quality language runtime for a much larger version of JS, implement a much wider selection of features and the APIs for that JS to use them, render graphical and multimedia content in various formats and allow that content to be generated or controlled in real time in addition to rendering the earlier basic images, potentially support a much wider range of functionality to adapt to different devices and interaction methods, and do all of this orders of magnitude faster to keep up with modern software architectures where a lot of the work is done client-side, and with a much greater attack surface to protect from a security perspective. Some of these changes are "only" quantitative. For example, although the specs have evolved, the basic rules for rendering simple HTML and CSS haven't really changed that much for a long time. Some of the changes are still substantial. For example, introducing tools like flexbox has significant implications for your layout algorithms that simply weren't there before. Some of the changes are qualitative, like introducing entire new areas of functionality to support off-line use or real-time client-server communications, or providing production quality support for graphical presentation via canvas/SVG/WebGL and multimedia audio/video players, which is essential if you are trying to kill off any external plug-ins that would have been used for such things before.
- pcwalton 11y ago
  > For example, introducing tools like flexbox has significant implications for your layout algorithms that simply weren't there before. Not really. Flexbox fits in pretty straightforwardly once you have CSS 2.1. Pagination and writing modes would be better examples.
  - Silhouette 11y ago
    I suppose it depends on how you interpret "substantial". I think flexbox, where just the layout algorithm from the W3C WD runs to about six printed pages, qualifies -- it might be quite systematic, but it's still a significant chunk of work anyone implementing a new browser engine today would have to do that someone implementing a browser engine a few years ago would not. As you point out, it's also far from the only such change.

FooBarWidget 11y ago

Because of momentum and backward compatibility. What you say may make sense from a purely technical point of view, but you are not considering that 99.999% of Internet users are average users. Without backward compatibility you have no way of winning. And with backward compatibility you have... the current mess of patches upon patches.

Silhouette 11y ago

For better or worse, the answer to your question is clear if you consider the range of functionality that users now expect to be provided by any serious browser. Browsers a few years ago had to render a page using HTML and CSS, supported some light scripting with JavaScript, allowed the inclusion of a small number of different image formats (primarily JPEG, PNG, GIF), and delegated any more serious interaction using plug-in technologies like Flash, Java, and ActiveX. Browsers today have to render a page using somewhat larger versions of HTML and CSS, provide a professional quality language runtime for a much larger version of JS, implement a much wider selection of features and the APIs for that JS to use them, render graphical and multimedia content in various formats and allow that content to be generated or controlled in real time in addition to rendering the earlier basic images, potentially support a much wider range of functionality to adapt to different devices and interaction methods, and do all of this orders of magnitude faster to keep up with modern software architectures where a lot of the work is done client-side, and with a much greater attack surface to protect from a security perspective. Some of these changes are "only" quantitative. For example, although the specs have evolved, the basic rules for rendering simple HTML and CSS haven't really changed that much for a long time. Some of the changes are still substantial. For example, introducing tools like flexbox has significant implications for your layout algorithms that simply weren't there before. Some of the changes are qualitative, like introducing entire new areas of functionality to support off-line use or real-time client-server communications, or providing production quality support for graphical presentation via canvas/SVG/WebGL and multimedia audio/video players, which is essential if you are trying to kill off any external plug-ins that would have been used for such things before.

pcwalton 11y ago
> For example, introducing tools like flexbox has significant implications for your layout algorithms that simply weren't there before. Not really. Flexbox fits in pretty straightforwardly once you have CSS 2.1. Pagination and writing modes would be better examples.
- Silhouette 11y ago
  I suppose it depends on how you interpret "substantial". I think flexbox, where just the layout algorithm from the W3C WD runs to about six printed pages, qualifies -- it might be quite systematic, but it's still a significant chunk of work anyone implementing a new browser engine today would have to do that someone implementing a browser engine a few years ago would not. As you point out, it's also far from the only such change.