61–70 of 214 posts
WebKit and jQuery -- and Bootstrap -- are becoming the new 'Win32 API.'
jQuery and Bootstrap, no. They are useful libraries, but developers can choose not to use them and still succeed. Few of the biggest websites use them, for instance--they mostly write their own javascript and templates.
But they all test against WebKit.
Earlier quoted context omitted.
That stuck out for me as well, I could argue that Chrome isn't a better browser than Safari for me , but functionally they're both using WebKit so they render sites identically in most cases.
Aside from JS performance, I'd argue that Chome's rapid updates make it a better browser. Safari as at best months old.
Replace "jQuery API" with "Web API" and this actually argues against John's point. Multiple implementations are better for everyone.
In the case of JavaScript libraries virtually everyone has standardized upon jQuery at this point. This guy really lives on his own planet. Maybe most websites that only need to add a small piece of JS functionality are using jQuery, but I seriously doubt that "virtually everyone" writing large JS projects is using jQuery. Google Closure Tools, Sencha/ExtJS, and MooTools remain quite popular, and a host of developers…
jQuery has a 90% market share[1] among JS libraries so I think it isn't an exaggeration. [1] http://w3techs.com/technologies/overview/javascript_library/...
Sure there is a long tail of sites that do use jQuery, but most of them don't do very much or get much traffic.
If you look at jQuery's market share by aggregate user sessions or by aggregate time on site across the entire web, it does not look nearly as important.
Earlier quoted context omitted.
You're right. The point he is making is that there is no need to maintain a rendering engine if it is no longer a point of differentiation when you can focus your efforts on improving the features that make your browser stand out.
Ahh, looks like I misunderstood, thanks. But will developers/users really flock to Opera just because it has a fast JIT? For me, Opera is just something to check for compliance.
I think it's the reverse: users will like Opera if it has UI features they like. It's highly unlikely that Opera would be able to beat Chrome / Safari on speed but there's plenty of room for innovation in other areas now that the web is becoming fast enough for most users.
Not having to support a modern browser engine just be able to start those features is the major win for Opera because they can focus on things users actually care about rather than obscure feature compatibility or baseline competitive performance.
Earlier quoted context omitted.
The cool part about jQuery is that I don't have to use it . Same with Bootstrap. So it's not a needless tyranny. With browser engines things get a little more political - mono-culture is not a good thing. But at least Firefox holds enough of a market share, and of course IE is now a much better player in this space - so WebKit can't get away with too much silliness.
Theoretically yes, mono-culture is not a good thing. Having more from-scratch rendering engines would be good for the robustness of web standards. However web standards are hugely complex at this point and it becomes increasingly infeasible to implement from scratch. With WebKit at least you have an open-source pluggable engine, so you're not talking about branded product monopolies where one or two bad actors can fo…
Gecko was an open source ostensibly pluggable engine (even MSIE is pluggable, in fact), so why did we need webkit to bring about the monoculture? Would advocates of it have been satisfied if it had come about then? Probably not, and rightly so, because Gecko has stagnated, as most large codebases managed by people with specific interests do.
And we are talking about branded product monopolies here. Should Google and/or Apple fall behind who's going to take up the cause of moving things forward again? People don't use webkit, they use Chrome and Safari.
In the past there was some amount of competitive advantage in owning the rendering/browser engine. You could add unique features, fix things your competitors wouldn't, whatever. These days performance is heavily driven by the javascript runtime. While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime. It seems unlikely Opera would have been…
Correct me if I'm wrong (and I very well may be), but isn't the JS runtime separate from the rendering engine? I was under the impression that Chrome uses WebKit for rendering and V8 for JS. So, even if Opera switches over to WebKit, that shouldn't affect JS.
So why opera instead of Chrome? They'll differentiate themselves with the UI, mouse gestures, ad-blocking etc.
Earlier quoted context omitted.
Correct me if I'm wrong (and I very well may be), but isn't the JS runtime separate from the rendering engine? I was under the impression that Chrome uses WebKit for rendering and V8 for JS. So, even if Opera switches over to WebKit, that shouldn't affect JS.
You're right. The point he is making is that there is no need to maintain a rendering engine if it is no longer a point of differentiation when you can focus your efforts on improving the features that make your browser stand out.
Increasingly, jQuery is not just an implementation, but is rather an API. That's why we're seeing the rise of alternatives like zepto.js that match the jQuery API de-facto standard but are implemented better (smaller, dropping IE6 compatibility). Replace "jQuery API" with "Web API" and this actually argues against John's point. Multiple implementations are better for everyone.
I'm not arguing against multiple implementations. If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous! Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine. I am arguing that the writing is on the wall for the common parts of a browser. A browser vendor's time will be used much more efficiently by collaborating with each other on the implementation instead of writing a number of separate implementations.
In the past there was some amount of competitive advantage in owning the rendering/browser engine. You could add unique features, fix things your competitors wouldn't, whatever. These days performance is heavily driven by the javascript runtime. While it's challenging to write a browser engine, it is much much more challenging to write a really fast JIT'ing javascript runtime. It seems unlikely Opera would have been…
That isn't really true. Sure, modern JITing js-engines are — arguably —the most technically advanced parts of a modern browser. However they are relatively small and self-contained; a suitably (i.e crazy-) talented team of engineers can get ballpark comparable performance of V8/Spidermonkey/etc. in a surprisingly short amount of time.
Most of the difficulty of making a browser fast is chasing the bottlenecks across multiple layers. For example it's no use having a super-fast javascript engine if your DOM implementation is so slow that real sites always bottleneck there. And there's no point in having fast DOM if your style layer is too slow to relayout when the underlying tree changes. And having a fast style layer doesn't help you much if your final compositing and painting are holding everything back. And of course different sites have radically different behaviour and what is an optimisation for one case might slow down a different case.