6 ms·

I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard

I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(

TazeTSchnitzel 14y ago
Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?
- natem345 14y ago
  Just like everyone used IE6 back in the day!
  - TazeTSchnitzel 14y ago
    Yeah, it was wonderful! The alternate browsers just accepted the standards dictated by the dominant browser, and that didn't cause any problems at all! /s
- jmesserly 14y ago
  Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
  - TazeTSchnitzel 14y ago
    Indeed. It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.
    - ConstantineXVI 14y ago
      Why not a JS implementation of a SQL database?
    - dragonwriter 14y ago
      > Maybe the solution would have been to specify a similar, new, SQL database for the web? That would certainly have been a solution, but I think one of the reasons WebSQL went with "use SQLite" as a shortcut was that it was a lot easier. If you specify a reasonably-implementable subset of SQL, you are stuck with that, and you can't piggyback on SQLite maintenance. I think the decision to abandon WebSQL for IndexedDB rather than expand the spec into something where independent implementations were feasible was probably based on the cost/benefit perceived with having to maintain a separate, browser-specific RDBMS implementation.
rictic 14y ago
I'll say from personal experience on two recent projects: if you're only testing in one webkit browser and not hitting the others there's a good chance that you're missing a couple of bugs. There are a ton of different ways to build webkit, Chrome and Safari were never identical enough to ignore. Fortunately, after developing in Chrome it took about as much effort to support Firefox as it did to support Safari, which is to say about half an hour.
- mikewest 14y ago
  Paul Irish has a great article outlining the technical background of this sort of inter-WebKit diversity: http://paulirish.com/2013/webkit-for-developers/ http://paulirish.com/2013/webkit-for-developers/
macspoofing 14y ago
>I had hoped every browser would eventually use the webkit rendering engine. WebKit is not a standard. Writing WebKit code, isn't the same as writing standards-based code. We lived through the ie days, why go back to those?

TazeTSchnitzel 14y ago

Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?

natem345 14y ago
Just like everyone used IE6 back in the day!
- TazeTSchnitzel 14y ago
  Yeah, it was wonderful! The alternate browsers just accepted the standards dictated by the dominant browser, and that didn't cause any problems at all! /s
jmesserly 14y ago
Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
- TazeTSchnitzel 14y ago
  Indeed. It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.
  - ConstantineXVI 14y ago
    Why not a JS implementation of a SQL database?
  - dragonwriter 14y ago
    > Maybe the solution would have been to specify a similar, new, SQL database for the web? That would certainly have been a solution, but I think one of the reasons WebSQL went with "use SQLite" as a shortcut was that it was a lot easier. If you specify a reasonably-implementable subset of SQL, you are stuck with that, and you can't piggyback on SQLite maintenance. I think the decision to abandon WebSQL for IndexedDB rather than expand the spec into something where independent implementations were feasible was probably based on the cost/benefit perceived with having to maintain a separate, browser-specific RDBMS implementation.

rictic 14y ago

I'll say from personal experience on two recent projects: if you're only testing in one webkit browser and not hitting the others there's a good chance that you're missing a couple of bugs. There are a ton of different ways to build webkit, Chrome and Safari were never identical enough to ignore. Fortunately, after developing in Chrome it took about as much effort to support Firefox as it did to support Safari, which is to say about half an hour.

mikewest 14y ago
Paul Irish has a great article outlining the technical background of this sort of inter-WebKit diversity: http://paulirish.com/2013/webkit-for-developers/ http://paulirish.com/2013/webkit-for-developers/

macspoofing 14y ago

>I had hoped every browser would eventually use the webkit rendering engine. WebKit is not a standard. Writing WebKit code, isn't the same as writing standards-based code. We lived through the ie days, why go back to those?