Live data from Hacker News

Web by Google (TM)

landshark.io

481–490 of 496 posts

Re: Web by Google (TM)

#481
post #323

Earlier quoted context omitted.

Even Chrome on iOS uses safari(webkit). There is no competition allowed on iOS, and that really sucks considering how terrible Safari is.

(as a web developer) As a user Safari is fantastic and basically the whole reason I even own an iPhone. It’s just stupidly faster than Chrome on any Android flagship. A world where there’s “choice” of browsers on every platform in practice just cements Chrome as the web because if you didn’t have to develop for Safari nobody would. On every other platform it’s “have bug-for-bug compatibility with Chrome or die.”

I'm not sure where people get this idea. Chrome on my old Note 8 is as fast as Safari on my newer iPad, and doesn't need to reload tabs as I switch between them nearly as often. On top of that, the Safari interface is completely unintuitive ("I have to hold which button to access that? I can't just tap it?").

I wouldn't even bother owning an iOS device if it weren't for the third-party app selection (specifically for art production). Which is the most infuriating part: devs could do all of this stuff on Android, they just refuse to.

Re: Web by Google (TM)

#482
post #323

Earlier quoted context omitted.

Even Chrome on iOS uses safari(webkit). There is no competition allowed on iOS, and that really sucks considering how terrible Safari is.

(as a web developer) As a user Safari is fantastic and basically the whole reason I even own an iPhone. It’s just stupidly faster than Chrome on any Android flagship. A world where there’s “choice” of browsers on every platform in practice just cements Chrome as the web because if you didn’t have to develop for Safari nobody would. On every other platform it’s “have bug-for-bug compatibility with Chrome or die.”

Safari on iOS is seriously the most buggy browser ever. You can mostly write something and it will work on Firefox and Chrome without issues.

Not only is safari full of bugs, the bugs won't be fixed, and if they do, it will take years.

Current serious bugs: 1. Add a site to the home screen, go to another app for 20 seconds and then switch back: congratulations, it's frozen. 2. You can't even stop scrolling on the body element, so tens of thousands of developers resorts to ugly hacks like eg. https://github.com/willmcpo/body-scroll-lock that kinda works in some situations. 3. The lack of features. Who doesn't as a developer feel bad for the person who spends forever trying every single browser in apples app store in an attempt to find a browser that supports push notifications. Of course none of them do, it's all Apple's shit.

You really can't have much experience with web development if you don't know how terrible iOS is for web as a result of Safari.

Heck, Safari isn't even behaving close to Safari. You have safari on desktop, safari on iOS and safari standalone on iOS. All of them behaves completely different and has different bugs and feature support.

Re: Web by Google (TM)

#483

Earlier quoted context omitted.

Promotion of any content results in the suppression of other content (inventory isn't infinite). If you were in charge of the algorithm, what would you promote? Considering half of America views CNN the same way you view Breitbart, do you consider that to be a despicable source too? It's really not as simple as you think.

How half of America views something doesn't really matter, what matters is that there is an observable factual difference between Breitbart and CNN. I don't have a dog in the race and that's pretty easy to establish. Or do you really believe that CNN also promotes conspiracy theories and outright nonsense? If so I guess the conversation is over.

> CNN also promotes conspiracy theories and outright nonsense

Yeah, I do. These outlets are all as bad as each other. The only difference is a right-leaning individual is biased in favor of Breitbart propaganda and a left-leaning individual is biased in favor of CNN.

Re: Web by Google (TM)

#484
post #386

Earlier quoted context omitted.

> dialup user of AOL didn't interact with each other that much back then because the internet wasn't as central to life like today. Speak for yourself as a kid I would go on AOL chatrooms all day every single day. The kids rooms were packed with at least like 30 instances of them and like 10 to 20 kids in between. Learned what a/s/l meant back then something you dont hear as often these days hah. MSN Messenger had MS…

Honestly, it seems like we never successfully replicated the AOL/Prodigy era chat room paradigm. My family still has friends we met in late-90s AOL chat rooms, and we honestly ended up stuck on their dialup for years longer than would have been sane due to wanting to stick to that community (at the time, I think the bring-your-own-connection service was still an extra fee, so we'd have to pay $15 to a local ISP plus…

> There's IRC, which tends to have a much higher technical barrier to entry though, and a lack of centralization makes for a more difficult discovery and user experience.

Some clients are nice enough to include a list of common / popular servers, but they don't provide much more context about them. I would love to see some of those modern IRCv3 features but I'm not sure of clients supporting them and IRC networks supporting them.

Re: Web by Google (TM)

#485
post #481
post #323

Earlier quoted context omitted.

(as a web developer) As a user Safari is fantastic and basically the whole reason I even own an iPhone. It’s just stupidly faster than Chrome on any Android flagship. A world where there’s “choice” of browsers on every platform in practice just cements Chrome as the web because if you didn’t have to develop for Safari nobody would. On every other platform it’s “have bug-for-bug compatibility with Chrome or die.”

I'm not sure where people get this idea. Chrome on my old Note 8 is as fast as Safari on my newer iPad, and doesn't need to reload tabs as I switch between them nearly as often. On top of that, the Safari interface is completely unintuitive ("I have to hold which button to access that? I can't just tap it?"). I wouldn't even bother owning an iOS device if it weren't for the third-party app selection (specifically for…

>devs could do all of this stuff on Android, they just refuse to.

That's not fair. There are good reasons Android doesn't have art production apps. The biggest is that Android users don't pay for apps like that and devs like eating, but iOS has several other advantages like the Pencil, the better graphics APIs, the better graphics performance, etc.

Re: Web by Google (TM)

#486
post #261

The real mystery is why nobody has ever been able to do better search than Google, or at least just as good. Of course search is really hard, but how is it possible that huge companies with nearly infinite money and talent (MS / Apple / Amazon) were never able to do it? MS actually tried; it's unclear if the others even gave it a thought. The rest of Google is different. I use Gmail but could easily switch. I've not…

> Of course search is really hard, but how is it possible that huge companies with nearly infinite money and talent (MS / Apple / Amazon) were never able to do it? MS actually tried; it's unclear if the others even gave it a thought.

What if selling phones and cloud compute is a superior business to search and they are smart to realize it? In reality both Apple and Amazon are bigger companies than Google, and Google is actually the one trying to chase selling phones and cloud compute?

Re: Web by Google (TM)

#487
post #290

Earlier quoted context omitted.

I still expect them to make a more coherent case, I still don't know what native means here, still don't know why existing solutions are different from what native means. It is not stated as a counterfactual either, it is stated as direct criticism, e.g. > The Web’s orignal architects were off base on hyperlinks; it turns out people just want to skip right to the answer they’re looking for. Who are the original archi…

Author here. The article is making a case that Google has in fact captured the Web, and secondarily that there are some clear reasons for it. I had no intention of writing a dissertation on the history of the Internet. Also, filling in the missing technical gaps would be several RFCs. As for what would native payments look like: 1. I put the element $1.00 in my HTML 2. User clicks on Pay Me button in any browser and…

Having an html tag, and even a browser that interprets it and connects to grandma's saved credit card is not the problem. But where does the money go to? It has to be a central body that holds all accounts and the page can specify their wallet id in another tag. How do you create that in the spirit of the open web?

Re: Web by Google (TM)

#488
post #481

Earlier quoted context omitted.

I'm not sure where people get this idea. Chrome on my old Note 8 is as fast as Safari on my newer iPad, and doesn't need to reload tabs as I switch between them nearly as often. On top of that, the Safari interface is completely unintuitive ("I have to hold which button to access that? I can't just tap it?"). I wouldn't even bother owning an iOS device if it weren't for the third-party app selection (specifically for…

>devs could do all of this stuff on Android, they just refuse to. That's not fair. There are good reasons Android doesn't have art production apps. The biggest is that Android users don't pay for apps like that and devs like eating, but iOS has several other advantages like the Pencil, the better graphics APIs, the better graphics performance, etc.

It is wholly fair. Developers have treated Android users like second-class citizens from Day 1. Android apps come out months after their iOS counterparts, with hobbled features that never reach parity. Customers have responded with second-class compensation (favoring advertising). Additionally, what you rationalize as "better" is better thought of as a result of expertise lock-in, as developers with more (exclusive?) experience developing for iOS favor that platform. Android is fundamentally more open as a platform, and Android apps would benefit if companies actually bothered to hire and incentivize Android developers as a priority. An especially damning example: the rapid development of ARKit-based technologies after YEARS of Google making its Project Tango resources available. ARCore still lags behind ARKit even though its underlying architecture had BEEN there for developers to explore and iterate on. They simply wrote off the very concept of SLAM-based interaction until Apple said, "Let's do this." It's embarrassing.

Re: Web by Google (TM)

#489
post #476
post #396

Earlier quoted context omitted.

I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly. Something like 30.00 USD 123456 https://secure.gateway.com" merchantid="123456" /> This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the r…

> There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000. If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?

While this is a bit of an after-the-fact view, it seems like there was a moment where they basically said "we've got enough tags." Richer and special-case capabilities tended to move into (first) applet platforms like Java and Flash, and later JavaScript and CSS enhancements atop a fairly thin platform.

I feel like this was the same stall-out that created "it took until HTML5 before we had a more or less universal slider form control" and "there's still nothing resembling a OS-native dropdown menu or rich-text widget in pure HTML."

That time period sort of coincided with the window of a couple years-- when we still had to think about 40-bit and 128-bit crypto offerings, you had to explicitly navigate to a SSL domain to check out, and things like Flooz were still considered a viable idea. Nobody really knew how to take a payment online, so we ended up basically copying the payment from from a mail-order catalog in HTML. A strong "this is the secure and easy way with big clicky buttons" proposal, supported by the leading browsers, would have steered the nascent market effectively.

Re: Web by Google (TM)

#490
post #475
post #361

Earlier quoted context omitted.

Like barrenko said in another comment [1]: >Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble. You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage.…

> Wasn't it that the creators of I don't know? Was it? > With a standard, those fights would be over and users could start paying for everything. What prevents anyone from making a standard? Why do we see standards for everything else but this? What would the standard entail? I think the real issue here is that payment is a hard problem, open payment systems like bitcoin is horrible to use, and closed payment systems…

>Why do we see standards for everything else but this? What would the standard entail?

Good question. hakfoo's answer seems to be a good start.

I would include something for automated micro-pre-payment. If you are just browsing news sites, it would be inconvenient to constantly confirm payment. Likewise, confirming payment for every played song is annoying. But that would also require some form of trust-network to take care of spam and fakes.

Like html, I wouldn't worry about getting it right the first time. It just needs to be usable and can be refined from there.

>What prevents anyone from making a standard?

Nothing. But where's the benefit for anybody to push it? If it is a standard, then all competitors can reap the profits without any investment.

This could have been Mozilla territory: Join Brave and make micro-payment a valid option for content creators.

Post reply on HN