Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure there's a path forward with fixing W3C standards to be simpler. Once a standard exists and has buy-in from multiple parties (in this case, browser implementers and website developers), it has lock-in; if a simpler standard isn't backwards-compatible with what's already out there, the implementation of the simpler standard isn't compatible with content on the web, and if that content is, say, Facebook, nobody will care about the simpler standard.

OpenGL ended up doing something like this with the death of the fixed-function pipeline (first via OpenGL ES omitting it from the parent standard and then via OpenGL's main standard marking it deprecated and killing it for all cards that don't mark themselves backwards-compatible). But the consequence of this is that some 3D apps simply won't work with some graphics cards (a situation users are accustom to in the brutal Wild West of high-performance gaming, so those incompatible cards aren't crippled in the marketplace for being unable to run older games and such).

Perhaps one could describe a simpler w3c standard that is an orthogonal set of "core" features, and then implement handlers atop that standard for all the legacy crap that browsers can do today? It'd be a hell of a project to even start identifying what the core feature set and architectural layer would look like.



There is a path forward: Just dropping support.

The web as a platform has done this before for things like ActiveX, Java applets, and most recently Flash. Collectively, developers decided they were overcomplicated rubbish and abandoned them.


Thanks. So, practically, developers can move capabilities deemed non-essential into plugins, which are more problematic to install, so end users would apply pressure to site authors to avoid certain technologies. Hm. History says it can work.


That fails to work if what you drop support for breaks Facebook. Newgrounds never had the clout of Facebook, but dropping Flash gutted them. In a world where Newgrounds had become Facebook, Apple would have invested in Flash instead of killing it.


Cynically, the users who need such websites shouldn't use that browser. Fewer users, but potentially more technologically literate ones. Sounds like a win-win to me.


IIUC, the goal has generally been to make browsers standards-compliant, not balkanize the space into multiple incompatible browsers.


I don't think the internet is well served by a monoculture of user agents all speaking HTTPS (and only HTTPS) and trying to cram everything under the sun into HTML/CSS/JS.

My personal preference would be for more specialized agents speaking protocols designed for their use case: email over SMTP/IMAP (or JMAP!), newsreaders with RSS, chat on XMPP, etc, content browsers with some limited markup language, maybe games and fat apps loaded as binaries to a sandbox VM.

Maybe this is unrealistic and that time is passed, but the internet used to work more like what I've described. Today, more and more things are just a JS webapp that only runs properly in Chrome.


> It'd be a hell of a project to even start identifying what the core feature set and architectural layer would look like.

If browsers are still "browsers" and not "kitchen sinks in disguise", I'd - still - identify 5 major parts: 1) networking 2) parsing (HTML/CSS/JavaScript - others?) 3) DOM rendering (images, video, audio too) 4) JavaScript engine and 5) controlling UI on top of all that.

Maybe it's too simplistic.


Thinking out loud: what about a transpiler project that goes from backwards-compatible current standards to stricter but more implementable standards. The idea is that you run everything you receive through this before your browser starts parsing it, so that you can support a larger part of the web while implementing a much smaller set of standards. Like Babel in reverse.

Of course, there's still a monoculture in transpilers, but at least there could be more browser competition after that point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: