duhi88

I have a Vizio Quantum X and a PS4 Pro both work great. YouTube videos show the occasional dropped frame on the Vizio app, and generally 0 dropped frames on the PS4.

I don't have the best speakers or room acoustics, but I can't complain about the sound.

Because this happens with every SV company that is often in the news.

Pretty sure that embeds enable all the tracking stuff you don't want, too.

There are plenty of devs outside of Silicon Valley. They don't have to look halfway across the world to reduce their costs.

I have to disagree with you there. Previously, I had to click on the tiny strip before I could see the languages. Now it is available right away.

For a new visitor, this is infinitely better because it is clearly labeled. For returning users, the only hurdle is getting used to the new location (which is made easy by the clear heading).

You could argue that project languages are more important than the contributors and should be placed above that content. Regardless, it is clearly a step forward.

I wouldn't consider any of your criticisms as being "less accessible".

To take your example of the languages, the new design is more accessible. It has a clearly labeled heading, and I can see the names of the languages are being used without clicking on the bar. The old design has no hints that the striped bar (or in the case of `linux`, grey) is supposed to be informative. We're all just used to clicking that bar if we're curious.

It's clear they've optimized the layout around productivity, and making it more approachable to new visitors. Everyone has their preferences, and new designs are always tough to get right for everyone. "Less accessible" is the wrong way to phrase your criticisms, though.

Ruby is definitely not new and shiny. There are plenty of long-lived Ruby on Rails projects that need to be maintained.

Makes sense not seeing React, though. It is far more complicated and fragile to get SEO-friendly pages rendered with React (and there aren't many legacy systems that use it, either).

I'm a "power user" and I like the change. It's not like it gets in the way when you're not using it.

By the way, what even is a power user on the web?

They made a statement within the last few years that they don't use GA data for their own purposes.

The scarier implication is they don't need GA to understand web trends. They can collect far more data using Chrome, AMP, Android, Ads, and more.

How did you have that conversation?

The clients I work for are all still worried about losing business due to dropping IE11...so we don't.

They have no analytics on which devices generate income, so it is hard to have that conversation. We know that IE11 hovers around 3% for most of our sites, and I doubt that many of those hits come from legitimate users, let alone someone who is going to purchase something.

I support the second half of your comment. All websites (webapps excluded) should strive for as little JS as possible. It isn't all that hard to support IE11 for most things, if you aren't doing anything super crazy with your design.

The first half though...we have grateful degradation for this reason. There's no reason to serve larger woff fonts to all users when it is so easy to use it as a fallback, preferring woff2 when supported. There are a lot of simple ways to improve the experience and data consumption for modern devices without sacrificing functionality in IE11.

Seems fine to me. There's still Bootstrap 1-4 to build outdated websites for outdated browsers with.

We gotta move forward. The web can't be held hostage over decade old corporate contracts.

there is, it just sometimes doesn't matter.

Styling an important or often reused component? You best find a better way.

Adding a tagline to a marketing site or temporary banner? Yea, do whatever you want to get the job done. Just don't let your whole site look like that or you'll have angry teammates.

Neat, but I find it hard to believe devs are going to reach for this verbose format without a default fallback.

hsl is a much nicer syntax for humans to describe color than rgb channels.

I'm sure there are good reasons under the hood, but why that syntax over something like:

``` header { color: hsl(42, 70%, 50%); color: hsl(display-p3 42, 70%, 50%); } ```

Yea, that's why I choose it, too. It isn't as opinionated as Angular, but it has enough structure that you know where to look to find most things in an unfamiliar project (my gripe when working on inherited React projects).

Rarely do I ever have to think about performance, and when I do, it is always complexity in the non-vue code, not the framework itself.

I use the web app version of Instagram, and I see no ads whatsoever, and I spend less time on it overall.

1. The study of wildlife migration patterns has been a thing for a long time. Methods exist, and are always being improved upon with better technology. A well-placed hunting camera could do the same thing without all the trendy Bay-Area BS.

2. I'm pretty sure that if (when?) a company develops drone-powered mass-surveillance technology, they will be doing it for someone other than ranchers.

3. This whole thing is really a non-issue. Individual wolf packs kill few cattle per year, and there are a lot of published papers with similar numbers. In fact, the removal costs of the wolves can exceed the potential lost profits.

You can get all of Lighthouse features in Google Page Speed Insights.

"read it later" window, sites for research, Slack in the browser, podcasts or music in the background, etc.

I usually don't close my research tabs until I've completed the task I was working on. Not having to worry about memory means I don't have to worry about finding useful webpages again.

It's the one reason I'm glad that all web browsers on iOS run Webkit.

Now if Apple could just fix their damn flexbox bugs and implement web app features...

It means that Google can push technologies that benefit their ad tracking business, or choose to use non-standard APIs to make their apps run faster than competitors. Both of these things they're already doing. While they might not go the route of Microsoft, putting their Active-X plugins in IE, using deprecated and non-standard APIs is pretty damn close.

Furthermore, all these forks result in bugfixes and new features making it back into Chromium. That allows Chromium to evolve faster than other browsers. That's not to say that Firefox hasn't been keeping up and pushing past Chrome on some important fronts (CSS Sub-Grid, for one), but I'm afraid a point will come where Firefox can't keep up with all the new web APIs that developers will want to use.

Another fork of Chromium doesn't lessen Google's influence over the market.

Just Google tracking everything you do in their browser, and preventing you from blocking other trackers.

Yea, I've run user feedback sessions. Page loads never come up as a complaint (plenty of other things to complain about :P)

The goal was to keep an average of <3.0s for the first meaningful paint, after login. Before login, all pages were treated with the same respect you'd treat any marketing page; render what you can as fast as you can.

Back with AngularJS, when code-splitting and lazy-loading modules/controllers wasn't an option, you had to get creative. Since moving to Vue, initial page load has never been an issue.

I'm a fan of these sorts of brands, too. I'd guess these products are hard to find because they don't show the same year after year growth you'd see with heavily marketed brands. Not the kind of returns a VC firm is going to want, anyway.

You need a stable brand, stable products, and patient owners.

---

You might be interested in N0-AD suncare, which does only sunscreen. I've https://no-ad.com/

In my experience, it's OK to have a (slightly) longer load time for content behind a login wall. I also spend extra effort caching whatever I can for return visits. Refreshing the page should give you an almost instant load time.

Then they could have chosen WebKit.

I get the Electron reason...it just sucks.

Well they could have picked up one of the other less-dominate browser engines. WebKit and Firefox are good starting points, and both could use the extra help maintaining their open-source core.

I get that they wanted to use the same browser as Electron, now that they own it...it just sucks.

Deploying JS (or anything) over the web usually requires a lot of extra considerations. Devs want flexibility in their deployment options, which is why Webpack is so complex.

Parcel is probably the closest to zero-config that I've seen. Only drawbacks are when you want to do something "off the rails". I'm guessing this project will be the same.

Of course, if you're not worried about supporting IE11, you could waive any built step and be absolutely fine. Gzip is more important than minifying.

Did previous generations not go out to eat? Or did they save money by going to Applebee's and Red Lobster over smaller, local options?

"Five years out"