WebKit Goals for 2020

https://trac.webkit.org/wiki/WebKitGoalsfor2020

by tompic823 • 7 years ago

170 148 7 years ago

trac.webkit.org

skrebbel• 7 years ago

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?

rwmj6• 7 years ago

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

kick6• 7 years ago

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.

saagarjha6• 7 years ago

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

scrollaway• 7 years ago

Django still uses Trac. https://code.djangoproject.com/query

It really is awful.

paganel2• 7 years ago

I’ve been using a Trac+Svn combination for my personal projects for 13 years now. I mainly use it for repository browsing, as I don’t do bug/task management for any of my personal projects, but it’s cool seeing repositories 11 or 12 years old. If it ain’t broke why would I fix it?

tmikaeld2• 7 years ago

I've been implementing FIDO2 into my serverless application, finally there will be iOS support!

It really is the golden authentication method, it's very thought through and incredibly easy to use (unfortunately not to implement though)

noja• 7 years ago

Can you recommend something to tie FIDO2 to generic web applications that don't support it directly?

tmikaeld2• 7 years ago

Do you mean like a plugin or API?

FIDO2 is not something you can "paste on" it has to be built-in to the login feature, but I guess for things like Wordpress there are hooks you can use.

I know of no plugins or APIs you can use to add it, I guess if they appear they will be listed on Yubicos list [0] or on Github [1]

[0] https://developers.yubico.com/Software_Projects/FIDO_U2F/U2F... [1] https://github.com/search?q=FIDO2

Important: U2F cannot be used as the only authentication method, unlike FIDO2 which fully replace password & 2-factor.

jlokier2• 7 years ago

FIDO2 is working, but I wouldn't call it "golden" at all.

Tying authentication to a single device you can lose, especially one controlled by the device vendor not by yourself, sounds highly risk prone to me.

As far as I'm aware, this is not yet a solved problem with WebauthN or FIDO2 standards - they simply recommend that you provide another authentication method or backup device for recovery, and leave it to you to figure out. (If I've got this completely wrong, I'd love to know.)

Although not the same thing, in a similar vein we're already hearing about people locked out of bank accounts that were created in a phone app, and Google doc accounts that they can't log into any more.

I wouldn't make the decision to run a business on the back of serverless services I could only get into with FIDO2 keys that are hidden in a vendor device that might die any day.

For now, I'll stick with backed up SSH keys and very secret passphrases :-)

acdha3• 7 years ago

It’s been a solved problem from the time it launched: you should never have one FIDO device since that leaves no room for failure. Every service I use except Amazon implemented this correctly[1] and the significant security improvements over TOTP or SSH keys are worth it, especially since phishing operations commonly bypass the easier schemes now.

1. You’ll need to find a notary if you lose your AWS MFA device

modeless3• 7 years ago

The Web Push API is missing. I was hoping for that one.

alexcroox• 7 years ago

A lot of companies build a native version of their web app just for push notifications on iOS. Unfortunately I doubt we’ll see web push any time soon.

soraminazuki3• 7 years ago

I avoid many native apps for the exact same reason. Too often I encounter apps that spam and spy on its users while providing no real benefit over a simple website.

xPaw• 7 years ago

Yeah that's a real bummer. Our open source web app [1] supports web push but it doesn't work on Apple's devices because they won't implement it.

The situation on iOS is even worse, because every browser is forced to use Webkit under the hood.

[1] https://github.com/thelounge/thelounge

asciident• 7 years ago

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.

Carpetsmoker3• 7 years ago

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.

wilsonrocks• 7 years ago

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.

Nullabillity• 7 years ago

Personally the problem is not that I don't like it, but that I have no way to test against it. No, I'm not buying their overpriced crap just to see what they've broken for their users.

Even MS has had modern.ie[0] for years. Until then, Safari users are on their own[1].

[0] https://developer.microsoft.com/en-us/microsoft-edge/tools/v...

[1] https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

izacus• 7 years ago

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.

Now imagine a platform where users are allowed to use a better browser which supports more image formats and saves their battery and bandwidth instead of being locked into a single closed piece of software for ever and ever.

And imagine a world where owners of that platform would understand something as historical as importance of free market competition and huge damage of DRM locked plaforms.

chipotle_coyote2• 7 years ago

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.

riazrizvi• 7 years ago

I appreciate this declaration

cdbattags• 7 years ago

No matter what, any and all improvements to JSC will do wonders to the React Native ecosystem and it's nice to have a list of targets.

newscracker• 7 years ago

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.

tannhaeuser5• 7 years ago

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).

crooked-v• 7 years ago

Notification support is already a thing, and is separate from PWA support.

cglong• 7 years ago

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

joneil• 7 years ago

Browser vendors are finally catching on.

From Firefox 72 permission prompts won’t be shown unless they’re triggered from a user interaction.

From the blog post:

Notification prompts are very unpopular. On Release, about 99% of notification prompts go unaccepted, with 48% being actively denied by the user.

https://blog.mozilla.org/futurereleases/2019/11/04/restricti...

I’ve heard Chrome is moving in a similar direction

lwansbrough7• 7 years ago

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.

asadkn• 7 years ago

No PWAs, no proper service workers, no native lazyload, no WebP, always lagging behind with more buggy implementation of almost everything. Can't blame people who call it the new IE6/8.

maximegarcia• 7 years ago

And web share target...

arciini• 7 years ago

There's been a lot of talk on this thread about the push notifications aspect. Setting that aside, at Wanderlog (https://wanderlog.com), we considered using PWA's and didn't because of another 2 WebKit limitations: storage and fast expiration.

We wanted to store pictures of where the user wants to go and cache map tiles offline. Mobile Safari has a limit of 50 MB. This is not enough for these use-cases.

Even more annoyingly, Apple deletes PWA's on iPhones after a few weeks. Our users often plan their trips months or many weeks in advance, and don't look at them for weeks at a time. By the time they go on the trip, they may be shocked to see that Apple has evicted their data from the local storage, just as they land somewhere where they no longer have access to 3G data!

I think Google's approach of providing virtually unlimited permanent storage is also probably not the best, but something in the middle might be better.

At the moment, it's clear that making PWA's capable is not an Apple-wide priority, even if the WebKit or Safari team may be in favor. We decided to avoid fighting it and build a native (React Native) app instead.

The_rationalist5• 7 years ago

Why not choosing Cordova/IONIC? Through it's 4000 native Java plugins it can do all the things a PWA can, and even more.

jxdxbx2• 7 years ago

I sure hope not. Why do I want web pages to be able to run persistent background tasks? Such an obviously bad idea. The tragedy is that Apple actually is implementing support for this garbage.

why-oh-why2• 7 years ago

Web pages will never run persistent background tasks on iOS unless you install them. And even then, native apps are also both highly restricted and often have background tasks that you wouldn’t approve of if you knew what they were.

iforgotpassword• 7 years ago

I sure hope not. Apple is the last bastion slowing down widespread use of these horrible technologies that have way more downsides than problems they solve. Privacy and increasing attack surface on your system are the primary concerns for me.

cordite• 7 years ago

I'm glad that battery life is a top priority.

Though WebP would still be nice to have..

berkut• 7 years ago

HEIF support in Safari would be nice...

pornel• 7 years ago

Apple already has HEIC codec on their systems, which is half the size of WebP.

I'm curious why they're not exposing it to the Web. Is it because the codec is a ball of risky C++ code? Patent issues? Or because it's non-standard, and for once, they don't want to add a non-standard feature?

There's also JPEG XL being standardized now, which gives similar compression while also supporting lossless conversion from the classic JPEG. This offers nicer migration path. With other formats conversion from JPEG is lossy, so you get smaller files partly because you lose quality in the process.

ksec• 7 years ago

Patent issues?

As far as I am aware HEVC issues is still not fully resolved. And likely unfit for Web usage.

altmind• 7 years ago

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"?

sirn• 7 years ago

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/

saagarjha6• 7 years ago

One of JavaScriptCore's optimizing JITs.

om23• 7 years ago

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.

214896• 7 years ago

Search "WebKit dfg" = https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

It's a layer of their JS pipeline.

rwmj6• 7 years ago

We use WebKitGtk[1] (embedded WebKit) in our presentation software Tech Talk PSE[2]. It would be great if SVG rendering, used for diagrams, was of equal quality to Firefox, but unfortunately Firefox seems to render SVG in a far superior way so we usually have to convert to PNG files to make diagrams embed correctly.

[1] https://webkitgtk.org/

[2] https://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/

SiVal3• 7 years ago

Unfortunately, converting to PNG doesn't work for interactive apps that use SVG as an interactive GUI instead of just a static vector image format. Of course, the user could just install Firefox (or Chrome) to get good-quality SVG support if Apple allowed it, which is why Apple doesn't allow it on iOS. After all, if Apple allowed you to freely choose a fully-working browser, they couldn't force you to use their Apple-only native technologies to get things to work well. It would be much harder to lock you and your customers (sorry, Apple reminds us that they are actually Apple's customers, NOT yours) into Apple's private world.

jwilk• 7 years ago

What software do you use for SVG→PNG conversion?

lwansbrough7• 7 years ago

No mention of PWA features (specifically manifest/installation/web push) is so lame. Classic Apple politics.

suyash• 7 years ago

PWA is not one single thing that needs a special mention, bunch of features they have listed will account for a better cross platform web & mobile experience.

lwansbrough7• 7 years ago

None of which particularly contribute to being able to supplant an iOS app with a PWA. Which is intentional on Apple’s part.

jitl• 7 years ago

Service Worker is the first step - they need to catch up there first. It’s on the list!

throwGuardian2• 7 years ago

How will they force you into the $99/annum developer program, shaft you a cool 30%, play judge and jury to your ios, macOs app store submissions and reject your work at the first hint of competition, if all the useful PWA features just work on iOS? Lest you dream of software freedom on Apple devices, their sycophants and overzealous employees will gaslight you into believing it's all for user experience and security, and any incidental monopolistic/anti-competitive byproducts are wholly acceptable collateral damage when the betterment of iKind, ahem, mankind is at stake.

threeseed• 7 years ago

You need to understand that many of us like Apple's approach.

We aren't looking for software "freedom" on our phones. We just want apps that are safe, curated, respectful of battery life and do not infringe on our privacy or user experience. Apple's approach gives us that.

So by all means complain about app store submissions but as a developer I don't have sympathy for other developers who play loose and fast with the rules.

kmlx2• 7 years ago

as is tradition already, webkit is missing:

- full PWA

- ServiceWorkers

- VP8/9

- webvr

- and many others

this could all be mitigated if aapl would let us install custom non-webkit browsers on ios. unfortunately it seems we will need the courts to force aapl.

xena• 7 years ago

iOS already has progressive web app support

kmlx2• 7 years ago

not full support, no

shantly• 7 years ago

Incidentally, is there a way to disable service workers on desktop Safari? Twitter’s went rogue the other day and started eating a whole core, non-stop. I don’t want or need them. Ever. Hopefully mobile safari doesn’t let developers do that to my phone, too.

acdha3• 7 years ago

Who’d benefit if they did? iOS users would benefit from AV1 but the only thing VP8/9 would add for web users is security exposure and lower battery life. Everyone serving video on the web already has equivalent quality H.264/H.265 and the next big change should be moving into the future with AV1 rather than spending millions to implement previous generations of codecs.

Similarly, as a developer I like the idea of Service Workers but as a user I’m forced to note that the only thing they seem to have added to my web experience are sites breaking in a way which requires more than a reload to fix.

mkurz• 7 years ago

Please finally implement the date and time input times! https://caniuse.com/#feat=input-datetime

paulddraper• 7 years ago

The fact that <input type="date"> still isn't a thing proves to me that semantic HTML, non-bloated JS bundles, etc. just will never happen.

dbbk• 7 years ago

It is a thing, just not in Safari

rptr_87• 7 years ago

Does webkit support Native messaging like chrome...?

https://developer.chrome.com/apps/nativeMessaging

The_rationalist5• 7 years ago

It's fascinating to see how pathetic this roadmap is. The totality (100%) of their planned features are already available on chromium. Guess what, even after that the chromium of today (not 2020) still has an order of magnitude more features, optimisations and testing. In human hours wise, comparing the number of full-time safari developers vs the number of full-time chromium (Google, Microsoft, opera, etc) developers is like comparing a third world country vs the USA GDP. Or more exactly: 217,369 commits vs 835,383 commits!

Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place.

If for whatever reason they wanted to opt out of some chromium features such as PWA they could still do it.

With such absurd politics, I wonder how Apple survived through history. Indeed the lack of rationality from the demand must help and irrational supply to thrive.

The_rationalist5• 7 years ago

Readers don't feel in accordance with my analysis. Sadly no thoughts have yet been outputed..

Razengan2• 7 years ago

Apple should just be rational and make the same synergistic move as Microsoft: migrate to chromium. It would save them R&W (reinventing the wheel) money, and they could allocate it to true R&D, allowing the web to move forward for making the world a better place.

Chromium is a descendant of WebKit in the first place...

With such absurd politics, I wonder how Apple survived through history.

Because users agree with them.

The_rationalist5• 7 years ago

Chromium is a descendant of WebKit in the first place... And safari is a descendant of KHTML, double standard I guess? The world change.

hirsin2• 7 years ago

Note that the logged in API is not supported in Chrom(e|ium). That WI be a big deal when finished because it will help with user privacy without breaking things.

The_rationalist5• 7 years ago

Interesting to know, but they could develop this feature inside chromium so it is a moot point. Moreover features only supported by safari will be used by exactly 0% of web developers.

SiVal3• 7 years ago

Apple apparently hates the name "progressive web apps", so how about: "offline web apps" or "installable web apps" or just "unrestricted web apps"? I'd like those names more, too. Regardless of the name, where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?

Apple keeps silently "considering" and "accidentally" messing up various aspects of web app support, while strictly prohibiting browsers that work well. By prohibiting high-quality browsers, Apple pushes developers toward Apple-proprietary "native" technologies--those that are both allowed to be the only things that work well on Apple devices and are NOT allowed to work anywhere else.

Two WebKit goals I'd like to see for 2020: (1) Allow non-WebKit browsers on iOS (start outperforming your competition instead of merely banning your competition), and (2) Make iOS the best platform for powerful web apps instead of the worst, the leader instead of the spoiler.

aphextron• 7 years ago

where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?

PWAs are a Google initiative for Android phones, with Mozilla and Microsoft simply following suit to get their products into Google's platform. Apple doesn't have that problem. They have their own platform with their own goals in mind. Non-native experiences are strictly inferior to native, and they know that. With quality being Apple's primary differentiator in the market, it only makes sense that they would take an extremely measured approach here.

SahAssar• 7 years ago

PWA is not a google-only thing, and if apple has better ideas for the implementation they should propose those, not implement a half-baked, buggy implementation of the standard agreed by all others years ago.

Native vs non-native is a red herring, there are performant webapps and slow native apps. There are accessible webapps and non-accessible native apps. If performance, accessibility or quality was the goal they would have stricter controls on their own store (as in not allowing apps that are basically "webpage-wrapped-in-webview" apps), as it is it seems that the goal is vendor lock-in and the revenue from in-app purchases.

saagarjha6• 7 years ago

start outperforming your competition instead of merely banning your competition

FWIW, Safari generally outperforms competing browsers on benchmarks.

greggman2• 7 years ago

WAT? I see Safari being substantially slower on pretty much every benchmark I throw at it.

Unless you:re on iOS where Apple bans competing browers

lern_too_spel6• 7 years ago

By using undocumented MacOS private APIs, which bolsters his point. On OSes that don't have this issue, other browsers perform better on the same hardware.

https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

This has been going on since WebKit launched with no effort from Apple to clean it up, so it certainly seems intentional. http://archive.is/MtntN

jxdxbx2• 7 years ago

Web apps suck and all the doodads and gewgaws that browsers now have to implement have made the web a surveillance nightmare that is a worse experience for publishing and reading.

There is a place in the world for lowest-common-denominator cross-platform apps, but I wish it wasn't my browser.

Razengan2• 7 years ago

Most modern web tech is trash and a crutch for lazy developers.

There. I said it.

In a blunt way what so many other comments here have tried to say without offending anyone. Redirect your ire. :)

At best most uses of such tech prey upon users' information, naïveté, and hardware resources. At worst they are outright malicious.

I'm glad there is at least one company with the muscle to put their foot down on this shit. We'd still be stuck with fucking Flash if y'all had your way.

Instead of reinventing a wheel that doesn't travel far to begin with, major companies should be putting a better effort into write-once-run-natively-everywhere technologies.

I don't care if it's SwiftUI, XAML, Qt or whatever. Just stop forcing everyone to spend most of their software time in a half-assed VM when we have had perfectly capable operating systems for millennia.

millstone4• 7 years ago

What is this hope for healthy browser engine competition? On Android and ChromeOS, Chrome and Chromium-based browsers have more than 99% marketshare.

"Apple should allow non-WebKit browsers" is really saying "what's holding back the mobile web is that Google does not completely dominate it." Only one thing prevents that outcome today.

lern_too_spel6• 7 years ago

That's a novel argument against allowing competing browsers. Let's apply a basic check on its validity. Do you think Mozilla agrees with it?

I think you'll find the answer is "no." Not allowing competing browsers does not help the web ecosystem or the users. It helps only Apple.

kitsunesoba• 7 years ago

Yes, this is precisely my fear. The moment that iOS is opened up to third party web engines and Blink-based Chrome has been ported, “viewed best in” badges will rise from the dead, and users will be badgered into installing Chrome for iOS, eliminating the last major non-Chrome holdout (Safari currently holds 16% marketshare). This will make Firefox extremely vulnerable with its ~4.3% marketshare.

coldtea• 7 years ago

Regardless of the name, where is WebKit's commitment to joining Google, Mozilla, Microsoft, and countless web developers in making web apps first-class apps on iOS?

Why should they make "web apps first-class apps on iOS"?

As an iOS user I'd rather they discouraged them.

The whole value proposition of iOS is getting fast, native apps, that directly use the APIs.

Not encouraging lowest common denominator implementations...

jpincheira• 7 years ago

I find it incredible that MediaStream Recording is still not out there on WebKit. They have taken so long to ship this. There's an open ticket[1] since 2012, and we still don't really know if they will implement this for sure on 2020, while Opera, Chrome, and Firefox already support this for years.

This is the main reason why we at Standups don't support video recording on Safari[2]. They are on the same level as Microsoft Edge, which also does not support video recording. It's hard for me to understand they did not want to catch up with the main players.

[1] https://bugs.webkit.org/show_bug.cgi?id=85851

[2] https://standups.io/help/not-using-chrome/

scottdeto• 7 years ago

What is "logged in API"?

hirsin2• 7 years ago

They broke most federated auth scenarios with ITP, so there needs to be a way for auth to flow between websites in a way that allows users to consent and control it. The logged in API basically takes your auth state (to a first estimate) out of the 3rd party cookies and into the browser. The browser then understands when to reinject them. Ad networks lose tracking via 3p cookies, but you stay logged in to your accounts.

greatjack613• 7 years ago

In response to all those complaining about no competing browsers on IOS. Why doesn't someone compile chromium for ios and then publish it using AltStore?

https://chromium.googlesource.com/chromium/src/+/master/docs...

https://altstore.io/

earenndil• 7 years ago

IOS requires all native code be signed so JIT wouldn't work. It would be a possibility on a jailbroken device, but someone would have to make a port.

why-oh-why2• 7 years ago

Isn’t that the whole point of AltStore? Apple certainly didn’t sign the GameBoy emulator available on AltStore.

The problem in this case is effort. It’s not that easy to port a browser effectively.

WebKit Goals for 2020

Related Stories