TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Chrome breaks the Web

1187 点作者 bloomca超过 7 年前

51 条评论

KeitIG超过 7 年前
&gt; they made all top-level event listeners passive by default. They call it “an intervention”.<p>This is my very problem with Chrome&#x2F;Chromium right now. The Chrome team does assumption on how things &quot;should&quot; be (in a highly subjective way) and breaks the web.<p>Another example: they decided to ignore the value of `autocomplete` attributes on `&lt;form&gt;` tags [1], because:<p>&gt; The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn&#x27;t mean there aren&#x27;t very valid cases where you don&#x27;t want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data.<p>Problem: Chrome now auto-fills wrong parts of forms with username&#x2F;passwords and this breaks forms that get unexpected data when submitted. And now, they opened an issue on their tracker [2] to track &quot;Valid use cases for autocomplete=off&quot;.<p>This is insane to think that the developer is wrong to use some attributes values, and to assume how a page should behave, ignoring devs intentions and Web standards.<p>[1] <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=468153#c164" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=468153...</a><p>[2] <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=587466" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=587466</a>
评论 #15635898 未加载
评论 #15636429 未加载
评论 #15635867 未加载
评论 #15635686 未加载
评论 #15636792 未加载
评论 #15635906 未加载
评论 #15636546 未加载
评论 #15641165 未加载
评论 #15637601 未加载
评论 #15638750 未加载
评论 #15638081 未加载
评论 #15637204 未加载
评论 #15640653 未加载
评论 #15636545 未加载
评论 #15637884 未加载
评论 #15640292 未加载
评论 #15651278 未加载
评论 #15640888 未加载
评论 #15636309 未加载
评论 #15660509 未加载
评论 #15636123 未加载
评论 #15653845 未加载
评论 #15635694 未加载
untog超过 7 年前
&gt; Turned out, Google wasn’t concerned about your websites at all. It was more concerned about its own product performance, Google Chrome Mobile.<p>As a web developer, I see this attitude a lot and it annoys me immensely. Another way of phrasing it: Google is putting users first, ahead of developers. This is as it should be. &quot;your&quot; website exists to serve users, if you&#x27;re doing a bad job at it then maybe it&#x27;s an opportunity for self reflection.<p>Janky scrolling behaviour on mobile has been a problem for a long time. Apple also implemented non-standard behaviour for years to avoid it. You should almost never be listening to scroll events in a non-passive way. The vast majority of times scroll listening is used, a passive listener is the correct implementation and just wasn&#x27;t available when the code was written.<p>This is proven by the article itself: the change was made in February of this year. Do you remember the internet breaking that day, and all of us rushing to update our event listeners? No, me neither. Did Chrome really break when the web when absolutely nothing broke?
评论 #15637307 未加载
评论 #15635852 未加载
评论 #15636049 未加载
评论 #15638743 未加载
评论 #15646086 未加载
评论 #15640473 未加载
评论 #15637965 未加载
评论 #15635679 未加载
Klathmon超过 7 年前
To be honest as a user, I&#x27;m glad they made this change, even though as a developer it might be a pain in the ass for a day or 2.<p>Scrolling on the mobile web sucked for a long time. Yes, updating the default broke many things, but the scope of that breakage was fairly limited in the grand scheme of things (like the author said, sliders, maps, touch-and-draggable things like lists are the biggest impacted, stuff like &quot;sticky headers&quot; and other junk would be impacted, but not &quot;broken beyond usage&quot;).<p>We&#x27;ve seen time and time again that simply giving a developer the ability to fix things doesn&#x27;t help, and letting the mobile web suck for several years while a few percent of the web slowly learned how to fix this would end up impacting far more people than the &quot;breakage&quot; ever would.<p>It&#x27;s not ideal, and I wish that google provided a very quick and easy way to &quot;opt out&quot; of the breakage (like some one-line &quot;polyfill&quot; that reverted the change that site owners could use as a stop-gap until they could properly update their apps to work correctly), but I see their point and as a user I agree with it, even though as a developer this is the kind of stuff that ruins your day.<p>I personally have not hit a single website that was impacted by this that I could notice myself. That&#x27;s not to say that I haven&#x27;t been impacted by the breakage, or used sites that had something break because of it (that I didn&#x27;t notice). But even knowing that this change was made when it was made, I didn&#x27;t see any sites that were &quot;unusable&quot; or &quot;broken&quot; because of it.
评论 #15635799 未加载
评论 #15636567 未加载
dotdi超过 7 年前
Dear developer,<p>I hate you[1] when you interfere with scrolling. Yes, some people do it right and so on. You are not one of them. Please. Stop.<p>Yours,<p>A user that will close your website when scrolling is messed with.<p>---<p>[1] not OP, but the average developer, which, under time pressure and without many resources, cannot test all desktop&#x2F;phone and browser combinations. Assuming they even care.
评论 #15636410 未加载
评论 #15637096 未加载
评论 #15637978 未加载
评论 #15636993 未加载
评论 #15635902 未加载
matt_kantor超过 7 年前
First of all I 100% wholeheartedly agree with the message of this post. However I have a minor quibble:<p>&gt; Chrome broke half of user websites, the ones that were relying on touch&#x2F;scroll events being cancellable<p>Either I badly misunderstood or the author is asserting that 50% of <i>all websites</i> rely on touch&#x2F;scroll events being cancellable. That&#x27;s inflated by at least 100x. Exaggeration is doing no favors here; the rest of the article is pretty rational despite it being clear that the author is pissed off, but this one sentence undermines it.<p>---<p>Unrelatedly:<p>&gt; We really don&#x27;t have more than anecdote (and our metrics) on the &quot;support&quot; side, and <i>no precise way to quantify the breakage</i>. I&#x27;d love to have a more quantifiable way to make these sorts of trade offs.<p>(Emphasis mine.)<p>Wow. So they&#x27;re breaking backwards compatibility in a standardized web API with no plan for how to measure the fallout? That&#x27;s not very nice.
评论 #15640930 未加载
Sir_Cmpwn超过 7 年前
I side with Google on this one. IMO we should be breaking JavaScript <i>more</i> often, especially in the name of performance, to make people use less JS and simpler JS on their websites.
评论 #15636176 未加载
评论 #15635610 未加载
评论 #15635630 未加载
评论 #15635612 未加载
评论 #15635621 未加载
评论 #15636609 未加载
评论 #15635917 未加载
评论 #15635587 未加载
ajross超过 7 年前
OK, this sounds bad. But... Devil&#x27;s advocacy here: are there any real-world examples of actual sites whose event behavior was actually broken by this change in Chrome 56? It happened a few months back, and I don&#x27;t remember anyone complaining.<p>I mean... it broke the author&#x27;s app. Probably a few others somewhere. But it seems not to have broken anything significant.<p>I guess I fail to see the concern here. It&#x27;s an edge case of an existing API that apparently &quot;no one used&quot;. Google found a way to get a benefit from exploiting a &quot;change&quot; in this &quot;unused&quot; API, presumably tested to make sure it was unused, and then went ahead and pushed the change over an 8 month period.<p>Is that really so awful? As someone who lived through the early &#x27;00&#x27;s and IE, this seems pretty benign to my eyes.
评论 #15638034 未加载
评论 #15640276 未加载
s17n超过 7 年前
&gt; As a user, I certainly do not care about “being part of moving the web forward aggressively”. Why should I? I like my stuff working, not broken.<p>Actually, I do want to be part of websites being faster, and I don&#x27;t care about the functionality that is being broken. Performance isn&#x27;t a secondary concern - if it&#x27;s bad, the site is unusable from my point of view.<p>Your shitty scrolljacking site breaks the web, Chrome is trying to fix it.
评论 #15637294 未加载
EGreg超过 7 年前
A lot of fair points in here.<p>I think what it comes down to is backward compatibility for the web. There are SO MANY websites relying on old behavior that introducing new behavior is going to break some sites that don&#x27;t KNOW about your shiny new shit.<p>IE used to have this kind of thing too, anyone here remember &quot;Quirks Mode&quot; and so on?<p>What web browsers sorely need is a backward compatibility standard that they can STICK TO. Such as feature detection as a first-class API to be tried first. Perhaps this way any new features can be detected across browsers. Like, they would actually have to coordinate to name EACH new change the same in EACH new browser.<p>But this is what you get when you have multiple browser makers. Some just won&#x27;t coordinate with the others and you need another layer - a library - to abstract away the differences.<p>Which is why it would be super-useful for browsers to add content-addressable protocols (read: not just http) to fetch files from any website in a DHT. So these libraries can be loaded ONCE and become cheap to use!<p>Does anyone know any mainstream browserd planning to implement, I dunno, IPFS? The only one I&#x27;ve heard of doing this is Blockstack and dude, how much adoption does that have exactly?<p>Last question -- can there be a browser extension that can intercept http requests by their Subresource Integrity checks, and load them on demand as if they were content addressed? Maybe use service workers in Chrome? Is that possible? I would be willing to partner with someone here to write such a thing.
评论 #15639517 未加载
ipedrazas超过 7 年前
&gt; Google wasn’t concerned about your websites at all. It was more concerned about its own product performance<p>Why I&#x27;m not surprised?
评论 #15635637 未加载
trgv超过 7 年前
Can&#x27;t they just add another argument for the options map without breaking backwards compatibility?<p>That&#x27;s ugly as hell too, but in a way that preserves backwards compatibility.<p>My feeling is that so many compromises have been made to maintain compatibility in JS&#x2F;DOM-land that it seems capricious to make this kind of decision now.
评论 #15635923 未加载
jarym超过 7 年前
It really feels like the Chrome developers have forgotten that they&#x27;re providing a platform and not an in-house Google service.<p>It happens very often - developers with experience building apps don&#x27;t always manage to build tools for other developers very well. They focus too much on the end-user and disregard their platform developers too much.<p>The balance needs to be somewhere but I doubt they have it in the right place currently. For example, how do Google&#x27;s own apps disable autocomplete if autocomplete is ignored?
评论 #15637306 未加载
cosinetau超过 7 年前
&gt; &quot;Browser vendors have their own agenda. It mostly includes making their browsers look fast, sometimes at the cost of your websites become broken.&quot;<p>I feel like you&#x27;d know the tree by it&#x27;s fruit. I have a little more faith that vendors like Mozilla wouldn&#x27;t pull a punch like this; might have been more receptive to community feedback, not that anyone here needs a continued lecture about Google.
acdha超过 7 年前
There’s a good point here but the clickbait trappings are holding it back, especially since passive listeners aren’t some obscure edge case which only Google needs.
评论 #15635687 未加载
diiiimaaaa超过 7 年前
I&#x27;ve seen similar posts when Apple announced that there won&#x27;t be Flash on mobile Safari. And I agree with Chrome team decision to force passive on document level listeners.<p>Also, note that not many people complained about &quot;blocking video&#x2F;audio autoplay on mobile browsers&quot;, because it&#x27;s good for users.<p>BUT:<p>- Passive event listener detection is horrible and it baffles me that they start thinking about proper way only now.<p>- The announcement of this breaking change was quite silent. Chrome has so many influencers on social media, but almost no one shared&#x2F;explained this change properly.
quotemstr超过 7 年前
Without commenting on the &quot;intervention&quot; itself: why change the signature of addEventListener? It would have been trivial to add a new addEventListenerEx API with a redefined final parameter, and this alternative approach would have made feature detection trivial.
评论 #15637410 未加载
iainmerrick超过 7 年前
I understand the push from browser vendors to (as they see it) encourage web developers to keep their sites up to date, but it&#x27;s crazy how little Google and others seem to care about backwards compatibility.<p>So many websites from 10 or 20 years ago are unusable now -- if they&#x27;re even still available. That seems to me a bit of a tragedy. It&#x27;s sad to just write off that entire slice of human history.<p>Funnily enough, it&#x27;s the sites that were quick to adopt the hot new HTML and CSS features from 10 years ago, but then were unable to keep updating indefinitely, that were the worst hit. Really old sites using basic HTML and CSS mostly work OK.
styfle超过 7 年前
Did anyone&#x27;s website or web app break because of this change in Chrome 56?<p>I ask because the article lists a couple things that could break such as drag &#x27;n drop but I have not noticed anything breaking in my experience.
评论 #15638070 未加载
datashovel超过 7 年前
A great example of why I think the entire core ecosystem of the web is backwards.<p>I&#x27;ve had a number of comments here on HN related to this. Imagine this same scenario, except instead of the User being in charge of deciding which engine is used to render a website &#x2F; webapp, the Developer is making that choice. What would a developer need to do if they were in control of which &quot;engine&quot; rendered their website on the user&#x27;s computer?<p>Instead of being at the mercy of Google &#x2F; Chrome, the developer of said site could simply change their HTTP Header &quot;X-BrowserEngine&quot; or something like this, and the client&#x27;s computer would know how to (a) download the new engine if it&#x27;s not on the computer already (b) sandbox the new engine (c) run the site &#x2F; app in said engine.<p>I&#x27;ve called this idea the &quot;Meta Browser&quot; in the past. It&#x27;s a concept for an app that sandboxes and runs sites on different browser engines seamlessly. The user experience is more or less as though they&#x27;re continuing to use a single app to browse the web, but behind the scenes could be any number of custom engines rendering the content.
lallysingh超过 7 年前
I don&#x27;t get this feature detection problem. The browser identifies itself in the request. Why not serve the right version at the beginning?
评论 #15635837 未加载
评论 #15635770 未加载
评论 #15635773 未加载
评论 #15640829 未加载
评论 #15636347 未加载
评论 #15635731 未加载
just2n超过 7 年前
This doesn&#x27;t surprise me. Having spent years working on a very complex web app that&#x27;s built to run primarily on Chrome (-2 versions), our API&#x2F;DOM usage coverage was so great that we would often joke that our unit and integration tests were effectively a 90%+ coverage of all of Chrome&#x27;s functionality, so any bugs or changes they made, we knew about immediately.<p>I think nearly every version introduced some change that broke behavior and had to be worked around, usually fairly minor and arguably reasonable. Sometimes that&#x27;s not the case, something would be completely broken and we&#x27;d file bugs against Chrome to get them fixed, and our codebase is now riddled with comments about workarounds citing Chrome bugs, some years old.<p>There was even a recent change to contenteditable that was a breaking change and is not spec compliant, which totally breaks HTML-based rich-text editing systems built on it that don&#x27;t want to just have a ton of style tags and&#x2F;or empty tags everywhere in their markup. This API is probably one of the worst I&#x27;ve ever seen (it needs to be extensible and modifiable, you can configure it somewhat but you&#x27;re left actually taking the output and massaging it yourself if you want anything resembling a good product based on it), so I&#x27;d be in full support of a rewrite of the spec and a new version of contenteditable, but as terrible as this one is, it should remain spec compliant.<p>At one point I held Chrome in reverence for pushing the boundary and improving the QoL of web application developers, but shifting to maintaining anything of decent complexity has made me regret the decision based on how much extra work Google makes for us. They really need to cut out the breaking changes and do better regression testing. If our app detects errors in beta&#x2F;canary and we report them and they STILL make it to live, I just don&#x27;t even know what to say. I&#x27;m not even sure I agree that just because 0.1% of websites rely on certain behavior that it should be &quot;breakable.&quot; With all this talk about progressive web apps, where are the progressive web browsers?
Fede_V超过 7 年前
I have a few contradictory thoughts on this.<p>On one hand, I really feel Chrome is more on my side than the average webmaster. I don&#x27;t want bloated websites, I don&#x27;t want autoplay videos, I don&#x27;t want copy&#x2F;paste blocked, I don&#x27;t waste text copying hijacked so that a phrase has a referral link to the article, etc. If Chrome breaks a website functionality to over-write these things, good.<p>The downside is that Chrome is a very big player and by working outside of the system then the rest of the web loses on the spillover benefits.<p>This is hard, committees are slow, bureaucratic and massively resistant to change - and saying fuck it, I&#x27;ll fix it properly for myself is a lot easier, and I have little patience for it myself. However, in the long ran this is probably better.
fiatjaf超过 7 年前
The highlighted comments from the Google agent are very jerkish, but to be honest,<p><pre><code> &gt; But in Chrome we’re fundamentally unwilling to allow the mobile web to continue to die from performance bankruptcy. Other browsers are less aggressive, and people who prefer to be more conservative (preferring maximal compatibility over being part of moving the web forward aggressively) should prefer to use a more conservative browser. </code></pre> is very true.<p>The mobile web is dying. Native apps are obscuring it while it is made irrelevant by very poor website performance.<p>Now I don&#x27;t know how to solve it.
marijn超过 7 年前
&gt; The gist of it: if you mark onscroll&#x2F;ontouch event listener as passive, Mobile Google can scroll your page faster<p>onscroll has never been cancelable, and is fired after the actual scrolling takes place. So I don&#x27;t see how it being passive by default changes anything. Is this an oversight in the article (and a bunch of comments here), or am I missing something?<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Events&#x2F;scroll" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;Events&#x2F;scroll</a>
bastijn超过 7 年前
Reading the comments here make me feel Chrome is like Uber. They may be right in that the standards are outdated and force change. Yet, it breaks all rules and regulations which they shrug off saying the rules have to change.<p>Again, this is not a comment to choose sides. Just an observation. As with Uber I can’t say if I’m in favor or against. By law, they are wrong. In time, it may turn out they have led change. Funny thing how you can get applauded as patriots for breaking the rules early as long as you were right in the end but critiqued otherwise.
评论 #15646300 未加载
mathias超过 7 年前
&gt; Which means you can’t practically use the new form without feature detection.<p>That does not follow.<p>`{ capture: true }` works in both, since it’s an object, and thus truthy.<p>There’s no need for feature detection in the case you describe.<p>Sadly, that’s the whole premise of this article.<p>It’s only a problem if you want `capture: false` combined with other options — since you’d need to pass in an object, that would be truthy in the old implementations expecting a boolean instead. But then again, the additional options wouldn’t be supported in those old implementations either.<p>I’m confused — what’s the actual use case that’s breaking here?
评论 #15637124 未加载
pasbesoin超过 7 年前
Many tech people learned this in the context of Microsoft in the &#x27;90&#x27;s, but it should be kept in mind universally:<p>&quot;Embrace. Extend. Extinguish.&quot;<p>Maybe stop placing primacy on the &quot;good&#x2F;evil&quot; aspects of this. Seems in part to work at a more fundamental level of human and organizational behavior.<p>P.S. I guess this could also apply to the people who hang ever-more JS off of their HTML skeleton, until our phones have to &quot;boil an ocean&quot; to load a page.<p>I guess that fits in with the &quot;universal&quot; aspect I described.
old-gregg超过 7 年前
<p><pre><code> &gt; they made all top-level event listeners passive by default. &gt; Now, this is a terrible thing to do. It’s very, very, very bad. </code></pre> I disagree. This is similar to popup-blocking, yeah the &quot;API&quot; is there, so lets allow every site to just open windows because they want to?<p>Executing code during scrolling is a hostile action performed by web developers against users. These listeners shouldn&#x27;t exist in the first place. Chrome developers sided with users, thank you Chrome developers.
Illniyar超过 7 年前
They broke userland.<p>They introduced a backwards incompatible change that causes a lot of sites to lose some functionality, behave differently or outright break.<p>Now you could say that the user (the developer here) used the feature wrong (I.e. they caused scroll jank), but that&#x27;s a bit disrespectful - sure there are a lot of developers who had no idea what it&#x27;ll do to performance, but others that weighed the options and decided that even with the jank the user experience for the majority of users is acceptable.
sbussard超过 7 年前
This sort of thinking is not &quot;moving the web forward.&quot; It&#x27;s the same thinking that created the IE6 problem — favoring browser-specific features over web standards.
nitwit005超过 7 年前
&gt; Think about it: a feature detection API that itself needs to be detected<p>There&#x27;s already at least one such feature in the form of CSS.supports: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;CSS&#x2F;supports" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;CSS&#x2F;support...</a>
anodari超过 7 年前
Adwords was asking me to test the new version, I clicked to update and it warned that only works in Chrome.
tehsauce超过 7 年前
I was a victim of this, thanks for pointing it out. Now I know what to fix at least!
Cacti超过 7 年前
Let&#x27;s be clear here, this isn&#x27;t a change in favor of users. This is a change in favor of Google, to speed up their browser, and in favor of their advertisers, for better overlay control.
评论 #15638662 未加载
hwu2whag超过 7 年前
Google is toxic for the future of the internet, but its services are convenient so from time to time a few of us will complain when they inconvenience us, like in this case, but will continue using Google products and completely forget about our grievance with this company.<p>Case and point, I don&#x27;t hear anyone complaining about amp anymore, or the fact that when you search for inventor in some US states you are presented with a bunch of irrelevant black people rather than actual inventors like Edison, Tesla, etc. Sadly, like with those cases this story too will blow over and nobody will care about it in less then a week.
creative-coder超过 7 年前
Thats&#x27; why contribute and stick to Firefox.<p>- Its more customizable - Its more open and standards-compliant - It doesn&#x27;t eat up all RAM - Its fast enough
est超过 7 年前
The main problem I have with the chromium team is that they removed Encoding menu.<p>I happen to visit an old unuqdated site from time to time now all I can read is gibberish.
JeanMarcS超过 7 年前
Back in the old days of IE &#x2F; Netscape web. When Microsoft thought the respect of w3c wasn&#x27;t fitting their vision. Yepee :(
avodonosov超过 7 年前
When Microsoft dominated the browser market they introduced non standard extentions. Now google dominates and does that too.
minusSeven超过 7 年前
Only thing I have to say in all this is any changes made on the web should always be backward compatible.
moocowtruck超过 7 年前
where you been? web been broken for awhile now..it&#x27;s all just duct tape and spit. We&#x27;re also repeating the sins of the IE days all over again with chrome.. At this point i&#x27;m using alternative browsers and only fire up stuff like chrome if i have to
Waterluvian超过 7 年前
Funtion overloading in a weak typed coersive language like JS seems like a bad idea.
halayli超过 7 年前
This is why Linus is very adamant to not break userspace applications.
glennblack超过 7 年前
The tricky thing is somewhere in the travel of the autocomplete
joering2超过 7 年前
Why the heck would they take out the checkbox on javascript alert box to &quot;not repeat anymore&quot;. Since they did, the only option to leave annoying website that pops javascript alerts in never-ending loop is Ctr+Alt+Del.<p>What were they thinking??
评论 #15638277 未加载
nasso超过 7 年前
When did this breakage happen? I dont remember it at all.
flight21超过 7 年前
Whining for not much, just update your code. I think the move is best for users and web performance!
francasso超过 7 年前
Jesus Christ, to think there are people in this thread defending what the assholes in the Chrome team did is unbelievable. You make breaking changes opt-in, that is API design 101. Linus should take over Chrome development.
评论 #15638014 未加载
评论 #15637224 未加载
nilved超过 7 年前
Google can break the Web because they own the Web. It&#x27;s their platform. Maybe handing it to them wasn&#x27;t such a good idea.
draw_down超过 7 年前
I agree with everyone else that this change is for the better.<p>What will we do when they decide to make a change that isn&#x27;t?
评论 #15646310 未加载
rpo1991超过 7 年前
Google is putting users before developers, which is dangerous because the users aren&#x27;t the ones holding everything together.