Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebKit Goals for 2020

trac.webkit.org

Post reply on HN
Print view View original

21–30 of 154 posts

Re: WebKit Goals for 2020

#21

Post by lwansbrough »

tannhaeuser wrote: post #13
newscracker wrote: post #9

Will 2020 be the year when WebKit, and the Safari browsers by extension, will have full and proper support for Service Workers and PWAs on par with other browsers? I recall reading that Safari lags behind on it, and the allegation was that Apple prefers native apps and doesn’t want web apps to be more popular.

Hopefully not. I'd hate to click through "This site wants to push new ads to you. Allow notifications?" modals on my shiny new iPhone (edit: in addition to content being constrained to poststamp-sized areas between GDPR banners).

You should understand the argument before you form an opinion on it. First of all, there are plenty of us who have legitimate use cases for web push. Second, if you care about being bothered by shitty sites prompting you unprovoked, you have a couple options: content blockers or use different sites.

The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a technical move or a users-first move. Making PWAs better on iOS runs counter to Apple’s walled garden business model.

Re: WebKit Goals for 2020

#22

Post by rwmj »

skrebbel wrote: post #2

Pardon the all-too-typical off topic: woa, Trac! I haven't seen that in a long time. I have fond recollections of its customizability. Is it still being used in anger and improving, or is this just a legacy system we're looking at?

Trac was/is truly to most awful bug tracking system. I mean a primary function of a bug tracking system should surely be to accept bug reports from users, yet Trac manages to make that the least discoverable and least usable feature. Even things like subscribing to an existing bug report or listing bugs are very hard to find. I would say "impossible" for ordinary people, but will get accused of exaggerating, but go and look at a Trac-based bug tracking system some time to see what I mean. One at random: https://trac.osgeo.org/geos

Re: WebKit Goals for 2020

#23

Post by kick »

cglong wrote: post #18
tannhaeuser wrote: post #13

Earlier quoted context omitted.

Hopefully not. I'd hate to click through "This site wants to push new ads to you. Allow notifications?" modals on my shiny new iPhone (edit: in addition to content being constrained to poststamp-sized areas between GDPR banners).

As opposed to every native app that says the same thing?

Making the web suck more to match the native experience would be stupid. If people wanted the inconvenience of native apps, they'd use native apps.

Re: WebKit Goals for 2020

#24

Post by kick »

rwmj wrote: post #22
skrebbel wrote: post #2

Pardon the all-too-typical off topic: woa, Trac! I haven't seen that in a long time. I have fond recollections of its customizability. Is it still being used in anger and improving, or is this just a legacy system we're looking at?

Trac was/is truly to most awful bug tracking system. I mean a primary function of a bug tracking system should surely be to accept bug reports from users, yet Trac manages to make that the least discoverable and least usable feature. Even things like subscribing to an existing bug report or listing bugs are very hard to find. I would say "impossible" for ordinary people, but will get accused of exaggerating, but go a…

Accepting bug reports from users isn't necessarily a goal of bug trackers: in some workflows mailing lists are better for unconfirmed bugs, the actual bug tracker is for confirmed bugs (read: not submitted by users). It works better that way a large amount of the time.

Re: WebKit Goals for 2020

#25

Post by chipotle_coyote »

wilsonrocks wrote: post #17
Carpetsmoker wrote: post #10

Earlier quoted context omitted.

Imagine being software developer with a sense of professionalism and dealing with your customers as they are, even if it's annoying a tad bit of extra work, instead of telling them to sod off if they're using a browser you don't like.

While I Personaly wouldn't drop JPEG support yet... Do non-web software developers support every CPU architecture? Because I'm sure I've heard of apps that not run on macs, or just windows and not Raspberry Pis.

You're trying to draw a comparison between app developers supporting multiple CPU architectures for their applications, and web developers continuing to use JPEG and PNG files for their web sites. I honestly just don't see how this comparison works.

Re: WebKit Goals for 2020

#26

Post by rwmj »

kick wrote: post #24
rwmj wrote: post #22

Earlier quoted context omitted.

Trac was/is truly to most awful bug tracking system. I mean a primary function of a bug tracking system should surely be to accept bug reports from users, yet Trac manages to make that the least discoverable and least usable feature. Even things like subscribing to an existing bug report or listing bugs are very hard to find. I would say "impossible" for ordinary people, but will get accused of exaggerating, but go a…

Accepting bug reports from users isn't necessarily a goal of bug trackers: in some workflows mailing lists are better for unconfirmed bugs, the actual bug tracker is for confirmed bugs (read: not submitted by users). It works better that way a large amount of the time.

You certainly want a good way to sort, classify, combine and remove reported bugs (which Trac also makes awful), but you should never put up barriers to accepting bug reports. My rule of thumb is that every bug that someone reports affects 9 other users who couldn't/didn't report it. (Probably with Trac it's 1:99 because of how difficult it is to use.)

Re: WebKit Goals for 2020

#28

Post by chipotle_coyote »

asciident wrote: post #5

No WebP? Safari is about to become out of date, and websites will stop working for it. I'm using WebP on my websites with no fallback to jpeg/png at the end of the year.

Okay, you've named one web site that will stop working for it at the end of the year, because of a choice you're explicitly making.

Re: WebKit Goals for 2020

#29

Post by ori_b »

lwansbrough wrote: post #21
tannhaeuser wrote: post #13

Earlier quoted context omitted.

Hopefully not. I'd hate to click through "This site wants to push new ads to you. Allow notifications?" modals on my shiny new iPhone (edit: in addition to content being constrained to poststamp-sized areas between GDPR banners).

You should understand the argument before you form an opinion on it. First of all, there are plenty of us who have legitimate use cases for web push. Second, if you care about being bothered by shitty sites prompting you unprovoked, you have a couple options: content blockers or use different sites. The need for notifications is real and Apple’s choice to exclude their availability in iOS is a business move not a tec…

> The need for notifications is real

Do you keep metrics on acceptance rates? How many of the notification prompts that you pop up are actually accepted? How much of the time are you just annoying your users?

Re: WebKit Goals for 2020

#30

Post by kick »

rwmj wrote: post #26
kick wrote: post #24

Earlier quoted context omitted.

Accepting bug reports from users isn't necessarily a goal of bug trackers: in some workflows mailing lists are better for unconfirmed bugs, the actual bug tracker is for confirmed bugs (read: not submitted by users). It works better that way a large amount of the time.

You certainly want a good way to sort, classify, combine and remove reported bugs (which Trac also makes awful), but you should never put up barriers to accepting bug reports. My rule of thumb is that every bug that someone reports affects 9 other users who couldn't/didn't report it. (Probably with Trac it's 1:99 because of how difficult it is to use.)

If you tell people to submit bugs to a mailing list, that means that devs will manually confirm bugs before putting them onto the bug tracker: this gives an incentive to get them taken care of faster, because right as it's added, someone who knows the codebase has a general idea of what's wrong.

Mail is standard, so it's not really a barrier. It kind of lessens the Caps-Lock Warriors of Bugzilla-like systems, though.

Post reply on HN