Opera pioneered a great deal of features that are browsing must-haves today, implementing them years before any competitor. I've been a fan of Opera browser for a very long time - I started using it right after it became free. That sort of sum could make or break Opera as a company. Not sure if Norway dev pay is equivalent to the US average, but you get the rough picture.
#Webkit vs blink software#
This sucks - for the developers, obviously, but I'm sure nobody was happy about making that call but according to, the average software developer salary is around $81,000/yr which times 90 developers is 7.29 MILLION dollars a year. By switching to Webkit (and now Blink) they were able to lay off over 90 developers, some of whom had been with the company for 15 years. Of course much of this about Apple adopting webkit2 for Safari all pure speculation, but then it has to be when you are talking about a closed source product like Safari and don't work for Apple. I have to admit, I have a gut feeling here that wrapping the multiprocess stuff around webkit ala chromium is actually a better idea than trying to do what WebKit2 is trying so I think the chromium devs might be making a better choice from a technical perspective even though it probably is a bit more resource hungry. Chromium won't need to use webkit2 because it is already designed to do what webkit2 does anyway. It seems that when Webkit2 is ready then everyone except Chromium will use it. Since Apple will probably throw webkit out the window anyway when webkit2 is ready it seems that everyone moaning about Google here may be a bit backward. Google have long taken the approach it seems to just have entirely separate processes for each page talk to a webkit subprocess via api calls.The webkit2 project are taking a different approach by trying to put multiprocess stuff actually into the webkit2 api itself. They have some pretty diagrams here showing the differences: It seems that the reason for this is to do with the upcoming webkit2 Apple project taking a very different approach to how multiprocess stuff should work.
I have just been digging around and think I can answer this question. Why not just make the choice of rendering engine user configurable? Stuff never goes away even if it is broken. Not a closed vs open debate more than a standard one. This is a classic lesson on why standards are so important and why going proprietary is bad. Logic is backwards but CMS never get replaced, sites stay, and users whine and blame YOU if something doesn't work. IE 6 and XP is still being used with its users considering an open standard broken because it breaks and broken standard to them which is open. Things stay freaking forever in the industry once it someone or a corporation is dependent on something. So if removing prefixed properties breaks some pages, that means they were broken in the first place. It was never good practice to use a prefixed property without its unprefixed version. The CSSWG agreement doesn't say anything about phasing out existing prefixed properties, but keeping them around with outdated syntax/behavior doesn't seem like a good idea. I hope they don't keep -webkit-* enabled forever.
0 kommentar(er)
