Does WebKit face a troubled future now that Google is gone?
arstechnica.com
arstechnica.com
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.
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.
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.
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?
Anyone that goes through the discussion threads from which this article originated from will see developers cordially debating about pertinent engeneering topics regarding the future of the project. Nothing more.
I personally think both projects will thrive as a result of this fork.
However, Betteridge's Law of Headlines was proven wrong by Betteridge himself. For example, "What was life like opposite Thatcher?" cannot be answered by the word "no".
The hard part is getting new people to pick up the features and functionality that was being worked on by people who have moved to Blink. That's going to be a huge challenge, especially for features that were half implemented.
Either the project will find/attract new contributors to support those features, or it won't. If it doesn't, it generally means it wasn't going to stay viable.
Plenty of companies left GCC and left features unmaintained. They either find new maintainers, or get removed, and the project moves on.
This is the life of an open source project. It's not like a divorce at all. It's like a large collaboration where people are free to leave at any time. When people leave, either the collaboration absorbs the loss, or it doesn't.
Yes, bad things happen all the time. Frequency doesn't turn a bad thing good though.
Folks who started EGCS, including a company worth of folks, left GCC to do so. Was this bad for GCC? Most people with gut reactions thought it was "bad".
It certainly ended up improving the state of the world, and in fact, later turned out very good for the GCC project because it got a much better GCC out of it.
Basically, I think you may need a little perspective here.