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

41–50 of 154 posts

Re: WebKit Goals for 2020

#41

Post by lwansbrough »

keeganpoppen wrote: post #37
lwansbrough wrote: post #21

Earlier quoted context omitted.

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…

wait is that "the argument" we're supposed to understand? you know, just because I use alert() in my code to debug doesn't mean that it should necessarily actually... work, and stuff... tl;dr - the tragedy of the commons exists; hence, lots of shitty technology that would otherwise be prone to it doesn't exist.

Not if you actually solve the problem.. which is basically just to make the permission only possible if the user interacts with the page in some way that satisfies a heuristic.

Re: WebKit Goals for 2020

#42

Post by kick »

rwmj wrote: post #39
kick wrote: post #30

Earlier quoted context omitted.

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.

Then they have to subscribe to the mailing list, which is another set of extra steps. Some people only know the web exists and don't even know mailing lists are a thing.

url: projectpage.tld/bugs

Hi! If you're here, you must have found a bug. Send an email to XXX@projectpage.tld describing the bug, and we'll see to fixing it as fast as we can, and we'll alert you when we've started working on it!

You don't have to have them subscribe, necessarily.

Re: WebKit Goals for 2020

#43

Post by saagarjha »

sirn wrote: post #33
altmind wrote: post #14

Hard to understand what each of this items mean since there is no tracking issue# mentioned. Some of items cannot even be googled, what's "Turbo DFG"?

> Some of items cannot even be googled, what's "Turbo DFG"? Data Flow Graph, JavaScriptCore's optimizing JIT. https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

One of JavaScriptCore's optimizing JITs.

Re: WebKit Goals for 2020

#44

Post by saagarjha »

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…

WebKit uses Bugzilla: https://bugs.webkit.org

Re: WebKit Goals for 2020

#45

Post by Carpetsmoker »

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.

Adding support for a CPU architecture is often a considerable amount of work, and the pay-off is often small, although this of course depends on what kind of software you have. For typical applications for end-users the cost/benefit ratio for supporting anything other than x86 is typically very low. For other types of applications like servers it's higher, so they often do support arm, s390, ppc, etc.

Supporting jpeg however is very low cost, with very high benefit: about 20% of browsers don't support webp. It's a small nuisance, not a substantial amount of continued investment of work like supporting a new architecture.

Re: WebKit Goals for 2020

#46

Post by lwansbrough »

kick wrote: post #23
cglong wrote: post #18

Earlier quoted context omitted.

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.

They do use native apps, because they offer these features and other conveniences only afforded to native apps within Apple’s control.

Re: WebKit Goals for 2020

#47

Post by om2 »

altmind wrote: post #14

Hard to understand what each of this items mean since there is no tracking issue# mentioned. Some of items cannot even be googled, what's "Turbo DFG"?

These are notes from a live presentation at the WebKit Contributors Meeting. All the items were explained live, there is only so much the notes can convey.

Re: WebKit Goals for 2020

#48

Post by rwmj »

saagarjha wrote: post #44
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…

WebKit uses Bugzilla: https://bugs.webkit.org

Bugzilla is also pretty awful (and I say this as someone who uses Red Hat's Bugzilla instance hourly in my job).

Re: WebKit Goals for 2020

#49

Post by rwmj »

kick wrote: post #42
rwmj wrote: post #39

Earlier quoted context omitted.

Then they have to subscribe to the mailing list, which is another set of extra steps. Some people only know the web exists and don't even know mailing lists are a thing.

url: projectpage.tld/bugs Hi! If you're here, you must have found a bug. Send an email to XXX@projectpage.tld describing the bug, and we'll see to fixing it as fast as we can, and we'll alert you when we've started working on it! You don't have to have them subscribe, necessarily.

Which is basically what I said in https://news.ycombinator.com/item?id=21490182 Never put up barriers to accepting bug reports. Now does Trac help in any of this? No.
Post reply on HN