3 ms·

Yet another article full of FUD and speculation. If this, if that, maybe this, maybe that. Seriously, please. Someone reform the media industry for me. Are ther

Yet another article full of FUD and speculation. If this, if that, maybe this, maybe that. Seriously, please. Someone reform the media industry for me. Are there any startups here doing this? Back to the article. WebKit won't allow hooking in random JS engines. Allowing this slows things down because many DOM access optimizations can be achieved by assuming a specific engine. This is totally reasonable thing. People who are complaining don't contribute to the project at all and are just armchair critics. Same goes for this web developer who is complaining on webkit-dev. He is an arm chair critic. Apple is talking about removing a feature that no one is stepping up to maintain. CSS variables is not a _standard_ and not close to being a standard and that is the key. If it was, Apple won't be removing it. I don't know whats worse - armchair critics or media creating whole articles based on speculation and armchair critics.

criley 14y ago
You're an armchair critic of armchair critics, how meta of you.
- general_failure 14y ago
  I am webkit contributor (committer). I didn't say it before because it doesn't matter to this conversation. And neither do I want my comment to have some magical weight because of my contribution status. Your argument is not valid though. I am not actively writing media articles 'prediciting' that WebKit project is going to have a painful time or going on webkit-dev telling people what to do.
saraid216 14y ago
Yes. Clearly what journalism needs is more profit motivation.
widdershins 14y ago
>Are there any startups here doing this? These kinds of articles generate more pageviews than boring, measured, and technically correct articles, so presumably if there were startups doing what you suggest, they wouldn't be doing very well. Media sensationalism stems from human nature, so it's not an problem I see being solved any time soon.
- CodeCube 14y ago
  So what about boring, measured, and technically correct articles ... with crazily sensational a/b tested titles :P but seriously, I wouldn't have a problem with a sensational title, if the actual article itself does a good job of arguing for or against said title.
DrPizza 14y ago
> Back to the article. WebKit won't allow hooking in random JS engines. Allowing this slows things down because many DOM access optimizations can be achieved by assuming a specific engine. This is totally reasonable thing. I agree, it's totally reasonable, which why I say in the article, "Removing the JavaScript layer is one thing; this was a piece of code that existed only to support Google's use of V8, and with JavaScriptCore now the sole WebKit engine, streamlining the code makes sense. Google, after all, is doing the same thing in Blink. " It may make things harder for some out-of-tree branches, so it's probably bad news for them, which is why it also suggests that, depending on their priorities, some forks might find it better to switch to Blink. > Apple is talking about removing a feature that no one is stepping up to maintain. Apple is also the richest technology company in the world. I would never pretend that this means that it can simply add new WebKit developers overnight. But equally, I have a hard time accepting that there will apparently be a _long-term_ developer deficit, such that the best option is to simply cull features now, rather than retain them for a couple of months while staffing is being increased. It's possible that features culled now will be restorable from version history in the future, but that rather depends on how many changes are made in the interim. If they're significant (integrating JSC more completely, ripping out things that Google added such as threaded HTML) then it's not clear that reinstating them from old versions will be trivial. I acknowledge that Google had an advantage here. By making the decision to fork, Google was in a position to make sure that it had the right people in the right places to maintain the codebase. Opera's involvement in Blink is probably helpful in this regard too. But come on. If Google can maintain this range of standards track features, is it really reasonable that Apple can't at least match it?

criley 14y ago

You're an armchair critic of armchair critics, how meta of you.

general_failure 14y ago
I am webkit contributor (committer). I didn't say it before because it doesn't matter to this conversation. And neither do I want my comment to have some magical weight because of my contribution status. Your argument is not valid though. I am not actively writing media articles 'prediciting' that WebKit project is going to have a painful time or going on webkit-dev telling people what to do.

saraid216 14y ago

Yes. Clearly what journalism needs is more profit motivation.

widdershins 14y ago

>Are there any startups here doing this? These kinds of articles generate more pageviews than boring, measured, and technically correct articles, so presumably if there were startups doing what you suggest, they wouldn't be doing very well. Media sensationalism stems from human nature, so it's not an problem I see being solved any time soon.

CodeCube 14y ago
So what about boring, measured, and technically correct articles ... with crazily sensational a/b tested titles :P but seriously, I wouldn't have a problem with a sensational title, if the actual article itself does a good job of arguing for or against said title.

DrPizza 14y ago

> Back to the article. WebKit won't allow hooking in random JS engines. Allowing this slows things down because many DOM access optimizations can be achieved by assuming a specific engine. This is totally reasonable thing. I agree, it's totally reasonable, which why I say in the article, "Removing the JavaScript layer is one thing; this was a piece of code that existed only to support Google's use of V8, and with JavaScriptCore now the sole WebKit engine, streamlining the code makes sense. Google, after all, is doing the same thing in Blink. " It may make things harder for some out-of-tree branches, so it's probably bad news for them, which is why it also suggests that, depending on their priorities, some forks might find it better to switch to Blink. > Apple is talking about removing a feature that no one is stepping up to maintain. Apple is also the richest technology company in the world. I would never pretend that this means that it can simply add new WebKit developers overnight. But equally, I have a hard time accepting that there will apparently be a _long-term_ developer deficit, such that the best option is to simply cull features now, rather than retain them for a couple of months while staffing is being increased. It's possible that features culled now will be restorable from version history in the future, but that rather depends on how many changes are made in the interim. If they're significant (integrating JSC more completely, ripping out things that Google added such as threaded HTML) then it's not clear that reinstating them from old versions will be trivial. I acknowledge that Google had an advantage here. By making the decision to fork, Google was in a position to make sure that it had the right people in the right places to maintain the codebase. Opera's involvement in Blink is probably helpful in this regard too. But come on. If Google can maintain this range of standards track features, is it really reasonable that Apple can't at least match it?