Live data from Hacker News

Chrome Won

andreasgal.com

431–440 of 583 posts

Re: Chrome Won

#431
post #394

Earlier quoted context omitted.

Nah, it's different. Google's evil is directly on the opposite side of the coin from their generosity. Google essentially "wastes" money just to promote the web itself. This is because the web is a fairly terrible platform, but they must promote it because they've capitalized on its flaws. If the internet exploded and we had to rebuild it from the ground up, there would be no html/web, and no 3rd party search engine…

In your hypothetical from-scratch internet, there's probably still a confy place for Google's flagship search engine. It's the ranking, it has always been the ranking. Nobody is interested in a rank of who paid the most for each keyword.

Sorry, the point was you can still rank them but you can build it into the system itself instead of having to parse it out or reverse engineer any information.

Re: Chrome Won

#433

Earlier quoted context omitted.

This ultimately was what made me switch back to Firefox after I had used Chrome for a couple of years. I regularly have several hundred tabs opened in my browser, and Chrome was completely unusable in that situation, at least back then.

Honest question: why do you use hundreds of tabs at the same time? Why not bookmarks and leave a couple of the most important ones open? I have never understood the use case for "hundreds" of browser tabs

If you want to be 10x, you need at least 10 stackoverflow tabs open to copy and paste from.

I've always assumed people talking about having hundreds of tabs open just don't understand how to properly use a browser. My grandmother, for example, usually has 100 or so open by the time I get a call about her having computer problems.

There's no logical reason I can come up with for doing this instead of using bookmarks.

Re: Chrome Won

#434

Earlier quoted context omitted.

Closed source is a boolean. Chrome is distributed only as a binary. I.e. it is totally closed source. It currently has a very large relation to the open source Chromium project. But Google could change that tomorrow if they wanted to - they could also gradually move more and more to their closed source Chrome builds (as they have done with Android).

Are there any viable chromium based open source browsers out there that have consistent updates?

https://vivaldi.com

Re: Chrome Won

#435

Firefox took marketshare from IE when that was impossible. It could do it again with Chrome, if things change a bit. Some problems with Mozilla are that they don't do community management well any more. In the old days, there were amazing grassroots-driven projects like spreadfirefox.com. It is not like that any more. Grassroots supporters have trouble participating, even if they try. For example, I tried to create a…

> They're killing off the API that it depends on.

Because they have to. Firefox could remain an unusable single-threaded XML behemoth, but what point is there in your wonderful extensible browser if it's an unmaintainable slow mess?

Re: Chrome Won

#436
Without starting any holy war arguments, why is Chrome adoption so high?

On the Windows machines at work, I use both Firefox and Chrome all day long for customer support and light web development. They're both pretty interchangeable for me, neither really being any better than the other. Since such high adoption of Chrome means the general public are using it, not just the more tech-saavy people like us, I doubt the reason is any deep developer niceties. So I don't really know why...

Re: Chrome Won

#437
post #291

Earlier quoted context omitted.

To be honest, all browsers currently on market are energy hogs and use massive amount of memory. God I miss the old Opera....

I do wonder how much of that is the browser's fault, and how much is because of website developers not understanding that we have a website obesity problem[0], nor the concept of "optimizing for fan noise"[1]. I'm fairly conscientious about this myself since I'm working on plotting data, and the dumb client-side number crunching involved is actually pretty good at eating CPU cycles. Most plotting libraries want to sh…

I wouldn't put this on the developer's shoulders always. I work for a major online retailer in my country and I'm always surprised of the amount of crap the people from business add to our site. All kind of tracking tools, surveys, push notifications, etc.

Re: Chrome Won

#438

Earlier quoted context omitted.

> Servo and Webrender[0] will completely shake up the browser landscape, and will allow web apps to match (maybe even surpass?) native mobile apps in terms of rendering performance. Unless Firefox (and Servo) gets it GUI to not feel alien and clunky, it wont matter if it has a faster rendering engine. Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users. And when pe…

> Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users. That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two. > And when performance does matter, it's mostly Javascript performance, which Servo doesn't address. If that were true, then there wouldn't be a performance differential betwe…

>That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two.

If we're talking about e.g. Electron apps, the problem I see mentioned (and felt myself) is almost always the memory hogging, the GC-pauses, the battery impact and such -- not the rendering speed. Although, there is talk of getting to 60fps web apps etc.

For something like Atom, is the slow redrawing because "DOM is slow" or because "doing the calculations needed for a sizable file, with syntax highlighting regexes, compiler checks, freeing memory, etc takes lots of processing time"?

>If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)

That's not entirely true, as Objective-C dispatch was thoroughly optimized [1]. Besides, the performance differential is also in the time to process logic (and the network latency) which you don't address. And of course, aside from rendering (which often is just "show a few forms, buttons and lists" for most apps) a part of the heavy logic in Objective-C for lots of tasks is done in C or C++ frameworks at much faster speeds than modern JS engines.

[1] https://www.mikeash.com/pyblog/performance-comparisons-of-co...

Re: Chrome Won

#439
post #436

Without starting any holy war arguments, why is Chrome adoption so high? On the Windows machines at work, I use both Firefox and Chrome all day long for customer support and light web development. They're both pretty interchangeable for me, neither really being any better than the other. Since such high adoption of Chrome means the general public are using it, not just the more tech-saavy people like us, I doubt the…

Personal opinion: Chrom/ium is significantly snappier for me, on a R7 1800X / GTX 1080 / 64GB RAM box. I can't speak to why from a technical perspective, but that's simply what I've experienced. Firefox feels significantly slower, so I stay away from it unless I have absolutely no other choice.

Re: Chrome Won

#440

Earlier quoted context omitted.

> Servo and Webrender[0] will completely shake up the browser landscape, and will allow web apps to match (maybe even surpass?) native mobile apps in terms of rendering performance. Unless Firefox (and Servo) gets it GUI to not feel alien and clunky, it wont matter if it has a faster rendering engine. Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users. And when pe…

> it wont matter if it has a faster rendering engine [...] its CPU use and battery impact that matters to users You make it sound like these are two orthogonal aspects. When rendering is faster, CPU usage obviously goes down. As does battery impact, since the CPU can go back to a sleep state faster.

>You make it sound like these are two orthogonal aspects. When rendering is faster, CPU usage obviously goes down.

Only as much as its the rendering, and not the core logic that consumes the CPU.

Degenerative case: a page with a single text entry field, where you enter a number and it calculates e.g. the fibonnaci sequence up to that number or factor primes etc. There's hardly any rendering, but lots of CPU.

Post reply on HN