Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

261–270 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#261
post #259
post #246

Earlier quoted context omitted.

If you're going to badmouth this decision, then please at least read the articles and address the reasons they mentioned. It's pretty stupid and pointless to make irrelevant generalist statements.

Well I just came across this: http://prng.net/blink-faq.html I think it shows (some of) the concerns really well. Not saying EEE is the strategy Google is trying to do here. But it's certainly a possibility and we should pay close attention IMO.

Wow, that is the most ridiculous thing I've ever read. Pretty sure it's a troll post trying to make frontpage with sensationalist bullshit.

For example, he claims it's a political move, yet the official FAQ lists many practical reasons for the move. Also, he says it will fragment the web: half the comments in this very thread explains why it won't. Then he says it's not open source because it's hard to understand how an HTML parser works? wtf?

Re: Blink: A rendering engine for the Chromium project

#262
post #220

Earlier quoted context omitted.

Isnt "take the tech, clone, tweak, and then don't contribute back" exactly the model Apple used to create webkit from khtml. If memory serves, the khtml team was incredibly unhappy with apple trying to submit giant monolithic and undocumented commits.

It was not ok then, and it's even more not ok now, considering Chrome's market share.

What Google's doing now is far kinder than what Apple did then. As noted above, Apple "contributed back" big monolithic patches. By contrast, Google is providing access to a version-controlled repository. The latter is far easier to work with, of course.

Re: Blink: A rendering engine for the Chromium project

#263

Earlier quoted context omitted.

Sincerely curious: why are you still a full-time Safari user in light of all those complaints?

Like most things, habit probably. Also, I used to work a lot on Safari/WebKit, so I guess sentimental value? That being said, I do like the way Safari "feels" a lot more than Chrome. I think Chrome is actually quite ugly, and bad from a UI perspective. For example, Safari's overflow tab menu is a much nicer solution than Chrome's insistence on shrinking tabs ever smaller until you can't tell them apart at all. Additi…

Try AutoZoom extension for Chrome which has different zoom levels for every website

https://chrome.google.com/webstore/detail/autozoom/ocdkpkoao...

Re: Blink: A rendering engine for the Chromium project

#264

Earlier quoted context omitted.

Yes. Announcing this especially today seems like a "fuck you" at Samsung. Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day? As if rendering engines are announced every other day, right?

This is a conspiracy theory. PR moves take time, so both Servo and Blink announcement probably baked for many weeks. The best explanation is both PR teams thought today is a good timing, probably because it is right after Easter holidays.

>This is a conspiracy theory.

Yes. And sometimes conspiracies happen. Conspiracies don't always involve aliens, illuminati or such. Sometimes they are as simple as "let's secretly aid the Contras in Nicaragua". Or "let's do our PR move at the same time to piss them off".

>PR moves take time, so both Servo and Blink announcement probably baked for many weeks.

Which makes it even more technically possible for someone to have learned of the other's date in advance, during all those weeks, and decided to announce his on the same date.

Re: Blink: A rendering engine for the Chromium project

#266

Earlier quoted context omitted.

Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.

> Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. Mozilla isn't WebKit. > I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the so…

http://www.ohloh.net/p/WebKit claims that WebKit is 4,825,108 LOC.

http://www.ohloh.net/p/mozilla claims that Mozilla is 11,614,049 lines of code.

Hmm. Not sure what to make of that, but the "we're removing 4.5 MLOC" claim still sounds ridiculous.

Re: Blink: A rendering engine for the Chromium project

#267

Earlier quoted context omitted.

>> We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. > Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective. Are you aware of the…

>Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks. The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Mem…

> So, I must be misunderstanding you, because it seems like you're suggesting that > you expected Chrome engineers to simply do all the work.

Nah, you're not misunderstanding, Apple/WebKit has a track record of doing this.

Re: Blink: A rendering engine for the Chromium project

#268

Earlier quoted context omitted.

and it gets fixed You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug. Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.

Indeed. Here's one example that's been open since Chrome 3: https://code.google.com/p/chromium/issues/detail?id=29502 Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.

That is a bug in WebKit and they've submitted patches upstream even...

Re: Blink: A rendering engine for the Chromium project

#269

Earlier quoted context omitted.

There already are speed differences in iOS alone. The native Safari has a faster JavaScript engine than the sandboxed Safari instances that iOS apps use. Or something like that. Something about security concerns.

It's the JIT for JavaScript that's disabled. I've never seen an official statement on it but I've read that it's that the security model in iOS does not allow compiling code and then executing it, but Mobile Safari gets a unique bypass for this security. Other apps which merely embed a UIWebView are stuck with interpreted JavaScript.

Any user process cannot allocate executable memory, hence you cannot have any JIT.

Re: Blink: A rendering engine for the Chromium project

#270
post #18

Standing ovation. This is most welcomed news since Opera's move to WebKit to keep the current browser innovation pace. Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs…

I know this sounds bitter, but I read this comment and my interpretation (of the ideology, not how you said it) is:

"Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally"

It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything.

I just see it as a sad circumstance is all.

Post reply on HN