3 ms·

>However, if there's one thing to learn from history, it's that situations change and usually in unpredictable ways. I have no idea what possible up-set to the

>However, if there's one thing to learn from history, it's that situations change and usually in unpredictable ways. I have no idea what possible up-set to the computing landscape could arrive and make Webkit unfeasible, but I'm pretty sure something will change eventually, and wouldn't it be nice if we had a backup plan? Sure, but that "backup plan" wouldn't be another similar engine codebase, like Trident or Gecko. I can't fathom any future technical case where those would do but Webkit would not. But I think I covered that in my comment concerning alternative engines. Make one if you have a real need to implement something different to cover a new situation or provide something not there today. Not merely to keep your own mostly same implementation that introduces slight incompatibilities and standards lag. Current alternative engines do the latter. >Also, consider what might happen if Webkit were the only browser engine. Sure, Webkit moves at a fast pace now, when it has competition from both other browsers and native apps, but consider that the two biggest supporters of Webkit both benefit directly from people using native apps over web-apps. Sure, they benefit from web-apps too, but Apple in particular gets actual revenue directly from native apps, so if they didn't have other browsers to compete with, maybe Webkit wouldn't be as shiny and cutting-edge as it is. I don't think this is true. For Google is isn't true at all: it makes more money from people using the web than from people using native apps. As for Apple, well, they started the whole webkit project, and they don't make much from native apps anyway. They make their money from devices (which are used to browse the web also, so need a top notch engine) and laughably less from selling native apps (it's just a side business for them). Plus, all this time with native apps and the like, they have enhanced Webkit and mobile Safari the same. But, let's say that what you say is true: if some companies indeed favored native apps instead of web apps, wouldn't that make even more important that all other companies that care about the web flock to maintain ONE and only engine, instead of working each in it's own engine? That way they could make it as good as it can be, remove compatibility issues and generally make the web attractive and achieve progress and new features faster. >The thing is, if Webkit were the only browser-engine, even if you did come up with some completely different engine, your idea would be useless. You wouldn't be able to achieve compatibility with existing sites without mimicking all the weird bugs and corner-cases of Webkit, which would not be feasible, and if your idea is so completely different you can't just fork the Webkit code and add your idea on top. The thing you describe as bad is actually BETTER than what you have to do today. Because today, if you come up with some "completely different engine", in order to "achieve compatibility with existing sites" you would not just have to "mimic all the weird bugs and corner-cases of Webkit" but also those of the other major engines. Better to have just ONE engine to mimic, no?

thristian 14y ago
> Sure, but that "backup plan" wouldn't be another similar engine codebase, like Trident or Gecko. I can't fathom any future technical case where those would do but Webkit would not. Certainly, any situation that made Webkit unviable would probably affect Trident or Gecko or Presto the same way. It's not that we specifically need to preserve some other code-base so that we can bust it out if something happens to Webkit, it's that we need to make sure that it's possible for new rendering engines to spring up and keep applying the pressure of competition. > Because today, if you come up with some "completely different engine", in order to "achieve compatibility with existing sites" you would not just have to "mimic all the weird bugs and corner-cases of Webkit" but also those of the other major engines. If the majority of sites each only worked in one major browser, or if they served completely independent markup to each browser, then yes, you'd have to reverse-engineer them all to obtain decent compatibility. However, that's not the case these days - the vast majority of sites stick to the parts of the Web platform that are reliably, consistently, interoperably implemented across the major browsers. If something has been implemented correctly four times, even if it took a while to reach that milestone, it's much, much, much more likely that it can be implemented a fifth time, than some feature that has exactly one implementation and it's not clear which behaviours are intentional, which behaviours are accidents, and whether the accidents must be preserved for compatibility reasons.

thristian 14y ago

> Sure, but that "backup plan" wouldn't be another similar engine codebase, like Trident or Gecko. I can't fathom any future technical case where those would do but Webkit would not. Certainly, any situation that made Webkit unviable would probably affect Trident or Gecko or Presto the same way. It's not that we specifically need to preserve some other code-base so that we can bust it out if something happens to Webkit, it's that we need to make sure that it's possible for new rendering engines to spring up and keep applying the pressure of competition. > Because today, if you come up with some "completely different engine", in order to "achieve compatibility with existing sites" you would not just have to "mimic all the weird bugs and corner-cases of Webkit" but also those of the other major engines. If the majority of sites each only worked in one major browser, or if they served completely independent markup to each browser, then yes, you'd have to reverse-engineer them all to obtain decent compatibility. However, that's not the case these days - the vast majority of sites stick to the parts of the Web platform that are reliably, consistently, interoperably implemented across the major browsers. If something has been implemented correctly four times, even if it took a while to reach that milestone, it's much, much, much more likely that it can be implemented a fifth time, than some feature that has exactly one implementation and it's not clear which behaviours are intentional, which behaviours are accidents, and whether the accidents must be preserved for compatibility reasons.