
Apple proposes new web 3D graphics API - mozumder
https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/
======
NickGerleman
"The major platform technologies in this space are Direct3D 12 from Microsoft,
Metal from Apple, and Vulkan from the Khronos Group. While these technologies
have similar design concepts, unfortunately none are available across all
platforms."

So Apple, the only company not supporting Vulkan on their platforms, is
complaining that there isn't a cross-platform solution?

~~~
om2
We're not complaining, we're explaining the lay of the land. Working on top of
all three of these APIs is totally doable and will result in a better API for
the web.

Things worth noting: \- We believe other browser vendors agree with us that
the web API should work on all three of the major native APIs. \- The web has
security requirements which force us to go a bit higher-level than Vulkan
anyway.

I understand your desire to have Vulkan on Apple platforms, but it's really a
separate issue from the right target for WebGPU.

~~~
hota_mazi
> I understand your desire to have Vulkan on Apple platforms, but it's really
> a separate issue from the right target for WebGPU.

No, it's not a separate issue.

If Apple supported Vulcan, the simple act of proposing this new API as a
standard would be laughed out of the room.

We can only speculate why Apple won't support Vulcan but I'm going to go with
"Prefer a solution they designed themselves over one designed by other
parties".

Just support Vulkan and let's abandon this silliness, shall we?

~~~
om2
I think you are wrong on that. Vulkan is a low-level native API, not a
JavaScript API for the web. Lots of design work needs to be done.

In addition, even on platforms where there are unofficial Vulkan drivers (such
as Windows), it's likely the natively available API will still have more
complete support and better performance.

So either way, we need a cross-platform graphics API.

Let's focus this discussion on improving the web platform, not fighting
battles about the underlying system APIs.

~~~
ioquatix
I think what you are going to find is that there is a lot of frustration
w.r.t. Apple not supporting Vulkan. One system for everything else and one
system for Apple.

> I think you are wrong on that. Vulkan is a low-level native API, not a
> JavaScript API for the web. Lots of design work needs to be done.

Nothing you assert here is invalid. But, I think you've missed the main point,
which is that people don't want an entirely new API, they want the same API
across all platforms. Vulkan, exposed directly in JavaScript as much as is
feasible (e.g. using an automatic API generation tool) would be awesome.

Simply look at how it is possible to cross-compile C/C++ to JavaScript. Now,
add in support the Vulkan API. That would be incredible.

> In addition, even on platforms where there are unofficial Vulkan drivers
> (such as Windows), it's likely the natively available API will still have
> more complete support and better performance.

Actually that's not correct. Vulkan was explicitly designed to be an efficient
and high-performance API. As it stands, even as a newborn API, it's the BEST
available for 3D rendering on all platforms that support it, unofficial or
not.

> So either way, we need a cross-platform graphics API. Let's focus this
> discussion on improving the web platform, not fighting battles about the
> underlying system APIs.

I think you are missing the point here again. As you say, we need a cross-
platform API. But, by that logic, accepting that JavaScript is just another
platform, we'd like the SAME API.

~~~
brians
Vulkan isn't designed for adversarial input. The web language has to be. That
alone is likely to require a ground-up redesign.

~~~
boardwaalk
But OpenGL wasn't either. I'd like to hear concrete examples of how it
couldn't be made workable. There are already validation layers that do a
pretty good job of checking for bad usage.

Especially since things like NaCl exist(ed) which are inarguably lower level
and still safe.

I think it's folly to create a whole new API before evaluating the option of
using Vulkan.

~~~
pjmlp
Which is a good example why I don't have any issues with native code on OpenGL
ES 3.x mobiles, while Chrome with WebGL is just choppy and dropping frames
left and right.

~~~
ThisIs_MyName
Naw, that's happening because you have a JS thread doing everything. Native
code on OpenGL ES is structured very differently.

------
shmerl
Will it be patent encumbered, like Apple's "proposal" for touch events API?

 _> Meanwhile, GPU technology has improved and new software APIs have been
created to better reflect the designs of modern GPUs. These new APIs exist at
a lower level of abstraction and, due to their reduced overhead, generally
offer better performance than OpenGL. The major platform technologies in this
space are Direct3D 12 from Microsoft, Metal from Apple, and Vulkan from the
Khronos Group. While these technologies have similar design concepts,
unfortunately none are available across all platforms._

Oh, really? And who is to blame, that Vulkan is not available on Apple
platforms?

~~~
om2
We're committed to abiding by the W3C Patent Policy for this spec.

~~~
shmerl
That's a positive thing, but the whole effort looks like an indirect attempt
to push Metal, without making it open itself. What about shader tools and
etc.? Are there any open ones for Metal? IMHO if anything like that should be
created, it should be based on open APIs.

~~~
om2
We think the eventual shader language will not be based on MSL. We need both
source and binary formats, and MSL doesn't even have a public binary format at
this time. However, if we do end up with something MSL-inspired, the same
commitment to follow the Patent Policy would apply.

~~~
shmerl
I think it's a sane expectation to use something that is both open and already
available. GLSL, SPIR-V and etc. Using something like MSL won't go anywhere,
if there won't be comparable, open and freely available implementation
already.

You should take that idea seriously, if you want to view it as a truly
collaborative project that invites everybody's participation. I.e using MSL
from the start was a major mistake.

~~~
BlackFingolfin
Quoting from their proposal:

> We don’t expect this to become the actual API that ends up in the standard,
> and maybe not even the one that the Community Group decides to start with,
> but we think there is a lot of value in working code.

I think it's pretty natural to write what is essentially a proof-of-concept
with tools one is ga,iliar with.

------
_ph_
For all arguing "to use Vulcan": the API proposed is a high-level API which
could be implemented on top of Vulcan. Or any other lowlevel API like DirectX
or Metal.

When designing an API, you have to take the characteristics of the calling
language into respect. Especially when you are trying to achieve the highest
possible performance. You can define highlevel APIs, which try to minimize the
amount of computation in the calling language, or a more lowlevel API, which
gives only very basic operations, and the client has to implement more logic
themselves.

When targeting "fast" languages like C/C++ you tend to design more lowlevel
APIs, assuming that the client can implement abstractions more efficiently as
they are more tuned to his needs. When targeting slower languages, you want to
do more computation in the API.

So for designing a new Web API, you both have to consider that Javascript is
slower than compiled C and on top of that, you have to consider security
requirements. Your API should not create an attack vector to your device. This
means, the best Web API would be an abstraction on top of the native low level
API and the only question with respect to those would be: can the proposed API
be implemented well and efficient on e.g. Vulcan?

~~~
madeofpalk
> assuming that the client can implement abstractions more efficiently as they
> are more tuned to his needs.

off topic, but who is the client?

~~~
_ph_
The part of the software calling/using the API. So, if you are writing a C++
application targeting the API, you should be able to implement high level
abstractions at least as efficient than an API provider could. Possibly more
efficient, as you can tune your abstractions to your very non-generic needs.
An API provider though has to implement the more common use cases which might
bring inefficiencies. However this turns around 180 degrees, when talking
about a language like Javascript, which despite all JIT enhancements does not
produce as efficient low level code. There you want to put as many of the
computations as possible into your API so the resulting application runs
faster.

~~~
madeofpalk
> tuned to his needs

Is there a specific person you're talking about, or just a programmer in
general? Does this have to be male, or are women also allowed to code?

I can only imagine the type of flack I'll get for raising this hear, but I
find it difficult to parse sentences that are overly specific about a general
collective of people. There's no need to mention gender here - consider using
something like "they" instead.

~~~
_ph_
Sorry, not a native English speaker here. In my native German, it is usually
proper to use the male form for the undetermined gender. This might leak into
my use of the English language. I would be happy, if you could rephrase the
offending sentence in correct gender-neutral English, so I could avoid this
mistake in future.

~~~
smaps
The correct way to be neutral in english would be "tuned to their needs"

~~~
RussianCow
Not to be pedantic, but the male form is actually also the neutral form in
English; "their" is not actually correct. That said, I think it's entirely
appropriate to use it in practice.

~~~
grzm
Singular _they_ is used and appropriate in English as well.

[https://en.wikipedia.org/wiki/Singular_they](https://en.wikipedia.org/wiki/Singular_they)

------
hutzlibu
It is so sad to see this whole discussion.

Because I usually think, HN is different, from the angry, uninformed mobs out
"on the streets".

I mean, I don't know much about low level graphic API's, I read about them,
but I don't work with them directly. But apparently most of the people here
don't know either!

They basically seem to know that they like open standards (so do I) and that
Vulkan is a open Standard and they heard of a possible WebVulkan so that must
be the solution then. Or just continue using WebGL. Because it works, right?

What they didn't heard of and what I came up with a bit of reading, before
posting anything, is that WebVulkan first of all don't exist and secondly
probably shouldn't exist mainly because of security. And that it is very, very
low level. (e.g. [https://floooh.github.io/2016/08/13/webgl-
next.html](https://floooh.github.io/2016/08/13/webgl-next.html)) And that
WebGL in itself has some flaws, so it makes sense to design a new API for the
future, without them. Because even though WebGL is working and awesome right
now, that's not a reason to not evolve ...

But why bother reading and really discuss a new WEB proposal, when "People
just want Vulkan on MacOS and/or IOS."?

~~~
lucideer
These are good points, but here are some more to consider:

\- Apple, particularly recently, have been terrible on supporting modern web
proposals. Worse than anyone. Much worse than the typical historical
reputational lower bar that is Microsoft.

\- Apple's record on _proposing_ new web standards has been demonstrably
aggressively anti-open and not generally condusive to promoting interop
[https://www.w3.org/2012/te-pag/pagreport.html](https://www.w3.org/2012/te-
pag/pagreport.html)

\- Apple's general record on cross-platform development is pretty much non-
existent. To the contrary, much of their business decisions are specifically
based on limiting interop with non-Apple platforms.

I think on a holistic level, if you take Apple's record into account at all,
any criticisms from them of a cross-platform proposal of any kind need to be
taken in context. Before you even start considering the pros and cons of
Vulkan or WebVulkan, there's a very blatant case of cui bono to examine behind
this.

Even if you do get past that, the points about commonality between native and
web APIs are growing more and more relevant every day as Emscripten,
WebAssembly and other such tech brings the two worlds closer to each other.
Cross-compilation efforts will invariably be made easier with a more
consistent API between (web and native) platforms.

~~~
hutzlibu
"Before you even start considering the pros and cons of Vulkan or WebVulkan,
there's a very blatant case of cui bono to examine behind this."

Not really. Because yes, it is well known that Apple closes down their system
and wants full controll over it and locks other partys out. One of the Reasons
for me, to not buy them.

But what does this have to do, when they propose a new Web API? If Apple
chooses to go a different way with metal (and a way apparently quite some devs
like), than I don't see much point in trying to force them to go another way.
Maybe metal is even superior - I can't judge that, but I am not going to say
vulkan is superior, just because it is open(even though I would like it to be
superior just for that fact). ButI don't see much point in dragging Web-
Technologys into these discussion in the first place.

Especially since apparently it is possible to implement the proposed WebGPU on
top of metal, vulkan or Direct3D !!

And even though "Cross-compilation efforts will invariably be made easier with
a more consistent API between (web and native) platforms." is true , it is not
gonna happen at the moment, since simply not everybody wants vulkan at the
moment, but 2 major players stick with something else. And I am not sure it is
only for power reasons, but maybe also for technical reasons, as I read from
quite some devs, that working with vulcan is huge pain(and they prefer metal,
if it would be open) .... as it is not made for working with it directly, but
rather to be worked through a higher level API. So ... is there a different
proposal for that higher level API than WebGPU to be discussed right now?

~~~
lucideer
> But what does this have to do, when they propose a new Web API?

The web being inherently cross-platform in nature there's a motivation on
their part to not support it, or - in this case - cripple it (perhaps to a
mild degree but at least enough to render it categorically inferior to native
metal and not worth the trade-offs). I can't say that their proposal does this
necessarily, but there's inarguably a motivation to do so.

For a previous obvious example of this kind of thing, see the deliberate
crippling of iOS UIWebView.

> I am not sure it is only for power reasons, but maybe also for technical
> reasons

Call me a cynic, but while there may be good, valid technical arguments
against Vulkan, it's mainly for power reasons.

~~~
hutzlibu
Hm, do you really believe, that Apple wants to artifical cripple the web?

I see, that they hypothetically might have motivation, to do so ... but this
is not valid, since the web is inferior to native implemantations in the first
place! The "only" advantage of the web is, that it is more or less, cross
plattform.

~~~
macawfish
As far as i can remember, they've been consistently behind on support for
emerging web technologies (since the app store came out), it just doesn't seen
to be in their business interests to keep up.

~~~
hutzlibu
But it is something different, to not "keep up" with full priority, than to
intentionally sabotage WebStandards ...

~~~
lucideer
The UIWebView is an interesting example. They released significant performance
advances in the iOS Safari web browser, but denied those features to
developers of cross-platform apps on frameworks such as Cordova, artificially
degrading the performance of Cordova apps compared to natively developed iOS
apps. Both need to go through the AppStore anyway, but keeping as much dev
lock-in as possible in terms of the tech used is obviously an interest here.

Add to that the fact that what positive feature development there has been in
Safari (e.g. the above-mentioned excellent es6 support in the Technical
Preview) has very specifically excluded the addition of any of the APIs that
begin to blur the web/native divide (web notifications, userMedia, service
workers, &c.)

~~~
hutzlibu
But where does your example show, that they sabotage webstandards?

It shows what I said before, yes they control their system and making it
harder for other implemations if they want ... but his is something completely
different.

------
ytugiuyghvk
Related reading re. Vulkan

"What a WebGL2 successor could look like and why it can’t be WebVulkan" \-
[https://floooh.github.io/2016/08/13/webgl-
next.html](https://floooh.github.io/2016/08/13/webgl-next.html)

See also the the author's sketch of a next-gen web graphics API on top of
WebGL
([https://floooh.github.io/2016/10/24/altai.html](https://floooh.github.io/2016/10/24/altai.html))
which is (perhaps unsurprisingl) broadly similar to the sketch given the
article (minus command queues, shader libraries, ...).

~~~
phire
Everyone here (including me) is upset that Apple are refusing to support
Vulkan (or even improve their existing OpenGL support).

They haven't even made a public statement.

And now we get the news that they are working on another API. It doesn't
really matter that the new API is targeting a completely different market to
Vulkan. It doesn't really matter that a WebVulkan can't really exist in the
first place. It doesn't matter if this is probally the correct starting point
for a NextGen web graphics API.

It doesn't even matter that the team at apple proposing this API is not the
same team that would be responsible implementing Vulkan in OSX.

People just want Vulkan on MacOS and/or IOS.

~~~
MBCook
So, you're mad about a desktop API choice and therefore any discussion
involving graphics API and Apple in any context must devolve into a fight over
what you care about? Not the topic at hand even if it is "probably the correct
starting point for a NextGen web graphics API"?

The Apple employees posting in here posting some really interesting stuff, but
it's all being drowned out by this noise that has little to do with the topic
at hand.

------
Benjamin_Dobell
I feel like Apple are just trying to get in early with a proposal so they
don't get forced into supporting Vulkan (and wasting all that effort on
Metal).

Mind you, it does at least look like they're trying not to be jerks about it
(even if the motivation is somewhat selfish). They specifically mention the
competition to Metal and how "webgpu" is ideally an abstraction that'll sit
on-top of Vulkan, Metal and Direct3D 12.

It'll be interesting to see how this pans out. Vulkan, Metal and Direct3D 12
are all intentionally very low level, adding a wrapper of any kind may be seen
as non-ideal by all parties.

~~~
om2
Is that really a "just" or is it the right thing to do? Working on top of all
the major APIs is the right thing for the web.

We've discussed our proposal a lot with key players in this space (including
other browsers, GPU vendors, relevant ISVs) and we're pretty sure a cross-API
abstraction is the way to go.

Some even want to build a form of cross-API abstraction at the native C/C++
level.

~~~
Benjamin_Dobell
No disrespect intended. You've undoubtedly got a much better grasp of these
APIs than I do! However...

> Working on top of all the major APIs is the right thing for the web.

A _standard_ is the right thing for the web. Whether that's an abstraction or
agreement upon an existing implementation remains to be seen.

~~~
om2
I agree with you that a cross-browser standard is the right thing. We worked
hard to bring all the interested parties to the table to kick off this
standards effort. What the output looks like remains to be seen.

------
nkkollaw
Apple proposing standards is ridiculous.

They only care about standards when they're basically forced to adopt/support
them, or they're their own.

These are the same guys that:

\- use lightning instead of mini USB

\- removed the headphone jack

\- are creating yet another proprietary connector for accessories

\- don't allow their OS on third-party hardware

\- only allow developing for iOS from macOS

\- only allow apps on iOS if you install from the App Store

\- only allow their own browser engine on iOS

\- etc.

Everyone wants their own standard to be the standard, if they really cared
about it they would contribute to Vulkan and create WebVulkan.

~~~
Tagbert
Apple’s “new” UAC port wasn’t made by Apple, and it isn’t new
[https://arstechnica.com/apple/2017/02/no-apple-isnt-
developi...](https://arstechnica.com/apple/2017/02/no-apple-isnt-developing-
an-all-new-port-for-accessory-makers/)

~~~
igravious
Eh? Seems you're _both_ wrong according to an Ars commenter[1]:

“It seems many people are missing the point of this. 3rd party cable makers
want to make certified cables that are Lightning to UAC port so people can
plug in iPhones and iPads into cameras that use these ports. Apple isn't
wanting to use this port, it is the cable manufacturers wanting to make
adapter cables to plug more things into iPhones and iPads.”

[1] [https://arstechnica.com/apple/2017/02/no-apple-isnt-
developi...](https://arstechnica.com/apple/2017/02/no-apple-isnt-developing-
an-all-new-port-for-accessory-makers/?comments=1&post=32776495)

------
gfwilliams
I'd like to see Apple implement Safari's missing functionality before they try
and come up with a replacement for WebGL.

Where are getUserMedia, MediaRecorder, WebRTC, filesystem, vibration, screen
orientation, Service Workers, Web Bluetooth ? What about WebGL 2? I'm sure
there are a few more I missed too.

Those are things that are really holding the web browsing experience back on
iOS/MacOS, not an extra 20% 3D performance and slightly shinier graphics.

Or why not lift the app store restrictions so that Google/Mozilla can actually
ship non-crippled web browsers and implement it all for you?

~~~
om2
We are working on many of the things you list. We are able to work on more
than one thing at a time though.

~~~
robert_foss
The features on that list are industry standard everywhere else. You 'working'
on them is not entirely convincing.

The sudden interest in a web graphics api is somewhat conspicuous coming from
a company known not to adhere to web standards.

There must be some reason for apples sudden interest in this stuff. Knowing
apple they're interest probably isn't aligned with their users interest.

~~~
gerardnll
"Knowing apple their interest probably isn't aligned with their users
interest." Explain cases please.

~~~
robert_foss
While going in-depth with this would be fun, it think mentioning some of the
proprietary cables they force onto their users is one simple example:

    
    
        * Non-standard headphone connectors (to force license costs onto manufacturer)
        * Proprietary bluetooth codec (to force license costs onto manufacturers)
        * Not using USB connectors on phones even though they were a part of the EU
          group that concluded that all phones have to have USB connectors

------
vvanders
Anything that's not based on the Vulkan spec is just a land-grab by Apple to
push their own technologies.

As someone who spends a lot of time in that space I don't really see what this
is solving, WebGL is good enough and anyone serious about performance/compute
are going to drop down to native anyway.

~~~
JoshTriplett
> As someone who spends a lot of time in that space I don't really see what
> this is solving, WebGL is good enough and anyone serious about
> performance/compute are going to drop down to native anyway.

Not true at all; if your primary performance bottleneck is the GPU code, not
CPU code, you could use a better web API modeled after Vulkan, for the same
reason people switch from GL to Vulkan.

In general, if there's ever something where people feel they "have to" use
native instead of web, that needs fixing in the web platform.

~~~
vvanders
As soon as you clear up that GPU bottleneck guess what's going to be your next
one? (Here's a hint, it's the thing that's dispatching to your GPU).

Another aspect that scares me about this is the security implications of
exposing compute to the browser. Esp when you start talking about unified
memory architectures. There's been more than a few exploits from a clever soul
calling glReadPixels in the right circumstances. Increasing the surface area
here doesn't seem like a great idea. Shader compilers are also great targets
for instability and obscure bugs.

~~~
JoshTriplett
> As soon as you clear up that GPU bottleneck guess what's going to be your
> next one?

Memory bandwidth for your textures, geometry, and other data, quite often. Or
nothing at all, if you can successfully reach your desired target framerate.

But if CPU turns out to be an issue, that's what WebAssembly is for.

~~~
vvanders
> Memory bandwidth for your textures, geometry, and other data, quite often.

So in other words a GPU bottleneck?

~~~
JoshTriplett
No, a memory bottleneck. (That may be GPU memory or system memory, depending
on the architecture of your graphics stack.) That's not the same as a GPU
processing bottleneck. You can have a bottleneck in GPU processing, or a
bottleneck in getting enough data _to_ the GPU.

~~~
vvanders
Oh I see, we're getting pedantic over semantics.

If your GPU is designed with a small bus between system and GPU memory, that's
still a GPU issue. You could make the same argument on the CPU side for caches
and DRAM if you want to go that far. I appreciate the education lesson but I
think you'll find most graphics programmers will consider it a GPU problem :).

At the end of the day though here's the thing. The intersection of users that
have a GPU capable of discrete pipelines, compute shaders and all the other
things that make this interesting but won't go through the effort of
installing a native app is relatively small. You can't polyfill(otherwise why
use the GPU in the first place?) on the users don't have a cutting edge
machine so you're going to have a swath of people that your WebApp won't work
for. From a value proposition it just doesn't make sense.

~~~
JoshTriplett
The reason for the distinction is that that's one of the specific things
Vulkan helps with: keeping the GPU well-fed with work to do. (Also, keep in
mind the architectural differences between integrated graphics and discrete
graphics.)

You potentially _can_ polyfill, if you have a graphics engine with a higher-
performance Vulkan/WebVulkan backend and a lower-performance GL/GLES/WebGL
backend. The Vulkan version will make better use of resources and allow you to
turn up the quality higher while still hitting the all-important framerate
targets.

All the same problems apply just as much if you go native as if you go web.
You either have to work with older APIs (often via an engine), or write off
older GPUs and some subset of users. Whether you can do that depends on what
you're doing.

------
vilya
All of you complaining about this proposal not being based on Vulkan seem to
be overlooking the fact that Vulkan is actually quite cumbersome to use.
Metal, on the other hand, is a really well designed API and in my opinion
strikes just the right balance between performance and usability. If it was
available for non-Mac platforms too, it would be my first choice of graphics
API every time. So for me, a cross platform web graphics API based on Metal is
really quite an exciting prospect - much more so than one based on Vulkan -
and I applaud Apple for proposing it.

~~~
panic
Yeah, have the people arguing for Vulkan on the web actually experienced what
it's like to use Vulkan? Here's a small taste: [https://renderdoc.org/vulkan-
in-30-minutes.html](https://renderdoc.org/vulkan-in-30-minutes.html)

~~~
filwit
There are many third-party libs which make using Vulkan much easier, all the
way up to Game Engines which abstract everything. That isn't a argument
against Vulkan.

A good graphics API, even a web one, is one that provides good control over
the GPU.. and to have sane standards which limit future implementation
fragmentation (like shader byte-code instead of a specific shader language),
and to have good debugging tools, etc.. That's what Vulkan is, regardless of
how verbose it is in comparison to OpenGL.

I'm not saying you can just make Vulkan run on the web, but I'm certainly in
favor of a Vulkan-subset (using SPIR-V as a shader base) becoming the
successor to WebGL over one inspired by Metal and MSL.

------
Zafira
I think this is a fruitful and promising discussion on the part of the WebKit
team. The biggest problem here is that the antipathy towards Apple in response
to the perception that Apple management thinks the Macintosh is a dead-end and
this is starting to infect other discussions.

As someone else noted, Apple created OpenCL, helped make it a standard and
dumped it. It embraced OpenGL when Mac OS X first came out and now it can't be
bothered to implement anything beyond 4.1. All of these little irritations
serve to remind people of the Apple of yore that had NIH in extremis and was
the gang that couldn't shoot straight.

The hostility is unfortunate, but I fear it's going to become more frequent if
Apple's senior management thinks the ship is fine.

------
sowbug
I find Apple Inc. as annoying as the next geek does, but I agree with them
here. It's rarely -- possibly never -- a good idea to tie a web API design to
a desktop API (see, e.g., WebSQL). The web platform is too different from
desktop platforms for any nontrivial functionality to port slavishly to it.

Moreover, web standards last much longer than typical desktop APIs. Do we
really want to take a snapshot of Vulkan's API today and live with it on the
web for the next couple decades, as desktop Vulkan continues to evolve?

It's better to build a web API that is fluent for its target platform, taking
care that it's possible to implement it performantly on foreseeable host
platforms.

Let Apple lock themselves in if they want. Don't lock the web into Vulkan.

------
jolux
Why exactly are we laying it on thick against Apple here when they have the
support of other browser vendors in proposing this and are trying to fix a
legitimate problem? All of the comments seem to be "well wouldn't it be nice
if they used WebVulkan instead" when WebVulkan _doesn 't fucking exist._ If it
were so obviously superior why isn't it in the pipeline already? Apple is not
the only company that can propose standards, if there was really such an
immense appetite for WebVulkan I think it would already have been proposed!

This doesn't even touch the reasons it hasn't been, and the most important of
these for me is security. "Well yes, it's extremely low level and admittedly
very dangerous, but we can make it secure enough to expose to the most hostile
environment in the history of computing" is how we ended up in the mess we are
in right now security wise. You want a secure system, you have to build it
that way from the start preferably in languages that don't let you decapitate
yourself like Rust. I'm pretty sure it's a consensus that it's impossible to
write secure C code these days, so why is everyone so convinced we could
sufficiently harden a low level graphics API for web use? This is like if when
NetScape proposed JavaScript if everyone went "well you're just trying to
dominate it, we already have C89 just put that in the browser." Fucking NO.
When are we as an industry and a discipline going to learn our lesson with
this "code first, secure later" crap?

And again, if this could be done and it's such a great idea, why is this the
first proposal and not actual WebVulkan? The argument here is not WebVulkan vs
WebGPU because again WebVulkan _does not fucking exist_. When or if it does,
perhaps we can argue about why Apple won't support it if they don't, but until
then, you're shooting down one attempt at a standard API with a hypothetical
thing that does not exist and which a lot of experts in the field seem to
think is a bad idea from several angles.

I will reiterate this one last time because it seems like everyone has missed
this: _there is currently no cross-platform solution for next-gen web graphics
except for this proposal_. Put up or shut up.

------
DigitalSea
Another anti-competitive initiative disguised as "Apple-led innovation" \-
maybe Apple should get on board with Vulkan, everyone else has, instead of
complaining about there being no cross-platform solutions.

~~~
eridius
How is this anti-competitive? They're explicitly trying to create a cross-
platform JavaScript API for graphics, one that can be built on top of whatever
platform-specific low-level APIs that exist. This seems to be the exact
opposite of anti-competitive.

~~~
nkkollaw
Because it's their own.

How convenient to propose your own standard as the standard, made specifically
for your own engine...

~~~
eridius
No it's not. I get the feeling you didn't really read the blog post. This
proposed standard is supposed to be able to be implemented on top of all 3
platform-specific APIs, it's not made specifically for Metal.

Yes, they're using the Metal Shading Language in this initial proposal. But in
the blog post they explicitly say that the choice of the shading language is
likely to be contentious (or, as they put it, "fun"), and so they're deferring
the issue right now and just picking the Metal Shading Language because
they're Apple developers. The actual choice of shading language in the final
version of this proposal is going to be the result of the standardization
process, and will probably not end up being the Metal Shading Language.

~~~
esrauch
While I'm far less negative about this blog post than most of the other
commentators seem to be, the part where you cite seems more like "well yeah,
we're proposing Metal, and that's obviously going to be contentious so lets
sheepishly point out that again this is all subject to negotiation".

My interpretation might be too uncharitable, or yours might be too charitable
by taking it at face value, it's pretty difficult to know without having
insider knowledge.

~~~
eridius
The blog post explicitly says they're choosing to "defer the issue". That
seems very clear to me as saying "we're not seriously proposing the Metal
Shading Language, this is just a placeholder for the purposes of writing up
this proposal, we'll let the standardization process decide on the actual
language".

~~~
esrauch
I understand what the text literally says, my point is that if a company
proposes a strawman that is literally just their proprietary solution on the
web any one liner disclaimer that says "but we're not actually _necessarily_
proposing that it use our proprietary solution for this (but maybe!)" can be
reasonably suspected as _potentially_ being disingenuous.

~~~
eridius
There's a whole standardization process to this, which everybody can
participate in. The whole point of the proposal is to kick off the discussions
and standardization process. Literally nobody expects the proposal to be
standardized as-is, so I don't think there should be any concerns whatsoever
about the fact that they punted on designing a new shading language.
Standardization isn't a "yes or no" vote, it's a process by which the
proposals are modified again and again until they come to a solution that
everybody is willing to accept. It's simply not possible for Apple to force
everybody to accept their Metal Shading Language.

------
sova
Go for it! I would love to see more focus on browser-based what-the-future-of-
code-may-look-like. That said, I don't think that 3D interfaces are the only
kinds that need good language / representation. Not that the rules should be
really rigid, but I think that if we pursue the notion of reversely symmetric
UI-languages we can make a lot of progress. Imagine that you have a 3D scene,
what is the minimal language you need to describe it? How can we make it so
that language/code is not only minimised but extensible? We must strike a
balance.

I would like to have such simplicity in a potential language that when I see a
scene in my minds' eye, it's really easy to transfer to the digital realm. I
think the simplicity of representation is key.

Being a web dev on my own hours for the past several years now has given me a
pretty solid grip of all the needs of an interactive application, and I can
say that there has to be some way for users to easily interact and offer all
the possible inlets for the information. Starting a 3D-internet movement might
require rethinking the inputs. Won't we just use holo-wands to navigate vast
swathes of data rapidly? Run through this field of data sheets...

So yeah, rethinking the medium will naturally come up as a question in
conversations around this, and I think that it's simply a matter of keeping
"user input" as straightforward and easy as possible, in the local _and_
distributed sense. With that as a foundational block, the rest of the 3D scene
can start to make sense.

~~~
kazagistar
Is this some kind of procedurally generated programming related nonsense?

~~~
sova
After reading it over a couple times I realize it may read that way. Just a
(terse) synopsis of some of my thoughts on the state and future of UI
"programming"

------
SquareWheel
I'm glad to see Apple getting interested in web standardization again, but I'm
not a big fan of this one. Wouldn't a WebGL 3.0 based on Vulkan make more
sense? I'd much rather see Apple warming up to Vulkan rather than have so much
Metal influence on a common web API.

From a dev perspective my thinking is this. If I were to learn a 3D graphics
API for the web I'd like that knowledge to be transferable to native
development as well. An API built on Vulcan - even if abstracted - would be
more pertinent and more compatible with existing tools than one built on
Metal.

I'll be curious to see comments from other committee members as they'd have
more insight on the subject.

------
unsigner
"Only platforms without Vulkan are Apple's" is most certainly NOT true. The
Xbox One is a widely available platform for which a lot of 3D effort is
invested, and rewards this effort really well - much better than other
platforms (like desktop Linux or old versions of Windows) that are frequently
thrown around as arguments for "Vulkan everywhere".

It is a common observation among game developers who have really tried both
that Metal is a much more accessible API than Vulkan; "90% of the performance
for 10% of the effort".

~~~
xxs
>>It is a common observation among game developers who have really tried both
that Metal is a much more accessible API than Vulkan; "90% of the performance
for 10% of the effort".

Any citation on the matter?

~~~
unsigner
No, sorry, this particular quote is from a private channel.

But see this:
[https://twitter.com/aras_p/status/749546349474054144](https://twitter.com/aras_p/status/749546349474054144)
[https://twitter.com/aras_p/status/767740566792724480](https://twitter.com/aras_p/status/767740566792724480)

and this:

[http://zeuxcg.org/2016/12/01/metal-
retrospective/](http://zeuxcg.org/2016/12/01/metal-retrospective/)

and this:

[https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan](https://twitter.com/search?q=from%3Azeuxcg%20metal%20vulkan)

------
warrenpj
An obvious use case for this API is to allow native games that use Vulkan to
be ported to the Web without a proprietary abstraction layer. (The abstraction
layer would be in the emscripten standard library rather than the game
engine.) But is this a legitimate use case that someone actually needs?

I can see two views here. Firstly, that as the open standard, Vulkan should
have a privileged position and be supported from the Web side, to make the
Vulkan -> Web -> Native abstraction layer standard, small and efficient. As a
developer you would just implement the necessary algorithms for your
application once, using Vulkan.

The alternative view is that Vulkan is just too low level and doesn't fit in
the web security model. Then, the purpose of WebGPU is not to implement Vulkan
in Javascript. Instead, it's another target in addition to the existing three:
Apple, Microsoft, Kronos, and web. To get maximum performance, developers must
write an application-specific, high level platform abstraction layer, and
implement that interface for each supported platform.

It seems to me that this article is of the latter view, especially as it
doesn't put Metal in a strategically weaker position than Vulkan.

If you don't need state of the art or original rendering techniques and
algorithms, I think there is already a high level abstraction which is
compatible with the web: OpenGL ES 2, and soon OpenGL ES 3. (WebGL & WebGL 2).

------
msie
MS doesn't support Vulkan! Why are many people bashing Apple as the sole
company not supporting it??? MS has abandoned OpenGL in support of D3D. Why
have people forgotten this???

~~~
jsheard
Microsoft doesn't _need_ to support Vulkan, because Windows is flexible enough
that GPU vendors can expose other APIs like OpenGL or Vulkan without
Microsoft's permission.

It's a very different situation to macOS, where Apple are the sole gatekeepers
of the graphics stack and nothing can ever happen without their direct
support.

~~~
vlozko
Not every GPU vendor or all the cards of a vendor support Vulkan. Even new
ones being sold today. The adoption is broad but not complete for Windows. I
guess the argument can be made that vendors ought to support it but that would
vastly expand the scope of any web API Vulkanization efforts.

~~~
jsheard
Support for Vulkan on Windows is pretty extensive - AMD and Nvidia are
retroactively supporting their hardware back to 2012, and Intel back to 2015,
all of them on Windows 7 and up.

Considering the lengthy turn-around time for these APIs (WebGL 2.0 took four
years to get from a draft spec to enabled in _some_ browsers by default), any
Windows machine that couldn't run WebVulkan would be rather long in the tooth
by the time the standard sees any real world use.

------
surfmike
How is this on security? Vulkan API is built on being able to modify command
buffers and pass parameters by directly writing to memory, rather than the
client/server model of OpenGL. I could see that being an issue with the
sandboxed model of the browser.

Disclaimer: haven't read the new Apple web 3D spec, just curious about others'
opinions.

~~~
om2
We haven't yet solved all the security problems, but we're aware of and
thinking about them.

We expect threadsafety, memory safety, data validation, and memory protection
for the shader language to be the big issues.

~~~
hrjet
Why are you proposing a new standard when you are still thinking about
security?

~~~
om2
Thoroughly solving the security problems will require more eyes on it than
just ours. Which is why we're proposing a starting point for a standard, and a
process to work on it, not an endpoint.

~~~
hrjet
Thoroughly solving security problems would of course take time. But the parent
comment asked a very high level question: How does the security of this new
proposal compare to a client-server model such as that of OpenGL? One can
simulate one model over another, but in that case, performance can suffer due
to overheads. This sort of thing needs to be addressed at the outset, because
graphics needs performance and the web needs security; neither can be
compromised upon.

~~~
om2
I don't think passing command buffers or structures in memory will be an
obstacle to security.

The main security issues will likely be: * Avoiding out of bounds memory reads
* Avoiding threadsafety issues * Figuring out lifetime for everything to avoid
enabling out of bounds memory reads * Coming up with a safe and validatable
shader format (probably a binary one, which makes validation harder) *
Checking correctness of things enough to avoid making drivers completely choke

We haven't figured out a lot of these deeper issues. We don't believe the
basic model is intrinsically harder to secure than OpenGL though. In fact,
OpenGL's complex drivers make security harder, because exploiting the driver
means a kernel exploit, so you have to be super paranoid about what you pass
to the OpenGL API. Modern graphics APIs have thinner drivers so there's less
risk.

------
AndrewKemendo
Biggest questions I have are:

1\. What is the (proposed) backward compatibility across devices?

2.Given that it is structured for Metal shaders, what are the plans for other,
non-apple devices? I see the hat tip to D3D and Vulkan, but I assume they need
to get on board first - any early takers? After all common standard means
cross-platform hardware support, something Apple has never really embraced.

~~~
eridius
The blog post explicitly says that they think that discussion around the
shading language to be "one of the most fun parts of the standardization
process" (i.e. most contentious), and they explicitly said they're deferring
the issue of shading language and just accepting an existing language "for
now", and that they picked the Metal Shading Language because the authors of
the proposal here are using Apple platforms. I think the implication is clear
that they don't expect the Metal Shading Language to actually be the final
shading language after the proposal has gone through the standardization
process.

~~~
AndrewKemendo
Yea I saw all of that, I'm wondering if it's just lip service or if they did
any outreach beforehand.

------
suyash
This is a great move by Apple. Webkit team is thinking ahead about power of
GPU's and opening it up for more than just 3D graphics. GPU are already being
utilized for AI and ML. Web developers need better access to low level
computation and simple api's.

------
thedjinn
The API looks like a direct port of Metal to JavaScript.

~~~
acqq
"We don’t expect this to become the actual API that ends up in the standard,
and maybe not even the one that the Community Group decides to start with, but
we think there is a lot of value in working code. Other browser engines have
made their own similar prototypes. It will be exciting to collaborate with the
community and come up with a great new technology for graphics."

Also, Metal was announced June 2014, released September 2014. Vulkan was
announced March 2015, released Feb 2016.

I don't see any reason for favoring Vulkan specifically for Web when compared
to Metal I can read: "Metal still does a lot of hand holding and behind-the-
scenes management for you, while with Vulkan you are responsible for —
literally — everything. And man they were NOT kidding when they said that the
API is explicit. Its actually quite ridiculous how difficult and detailed the
API is." (1)

1)
[https://forums.developer.apple.com/thread/38469](https://forums.developer.apple.com/thread/38469)

~~~
SquareWheel
>Also, Metal was announced June 2014, released September 2014. Vulkan was
announced March 2015, released Feb 2016.

It was rebranded then, but OpenGL Next was announced in August 2014.

[http://www.anandtech.com/show/8363/khronos-announces-next-
ge...](http://www.anandtech.com/show/8363/khronos-announces-next-generation-
opengl-initiative)

------
elFarto
I'm not quite sure what Apple were expecting, when they have shown a clear
contempt for OpenGL by leaving it at version 4.1 (while everyone else is up to
4.5, even Mesa).

But to the people saying use Vulkan for the web API, that wouldn't be a good
idea. Vulkan is a very verbose low level API.

Here[1] is a sample for the most basic of renderers (renders a single
triangle). That's 1,000 lines of (commented) code. It's not a good fit for web
development. A far better solution would be to evolve the current WebGL API,
than shoehorn Vulkan into somewhere it was never meant to be.

[1]
[https://github.com/SaschaWillems/Vulkan/blob/master/triangle...](https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp)

------
TazeTSchnitzel
That API looks potentially more pleasant to use than WebGL, which is a nice
surprise given it's purportedly more low-level.

~~~
om2
That's one of the benefits of designing an API for the web from the get-go,
instead of just literally copying an API that's meant to be used from C. It
makes for a cleaner and nicer API, even though some lower-level details are
exposed.

~~~
flohofwoe
It's basically a webified Metal API, similar to how WebGL is a webified
OpenGL, so I wouldn't say it was designed from the get-go for the web. And as
far as I can see from the proposal, WebGPU will still be well usable from C
(this is important for talking to it from asm.js / WebAssembly)

~~~
om2
It's Metal-inspired, but we tried to use JS API design idioms where possible.
It does help that Metal is already an object-oriented design instead of bare
functions passing around primitive values and structs.

~~~
flohofwoe
Ha, sorry I wasn't aware that you're on the WebGPU team when I replied. Please
don't forget about us emscripten users, I'd love to give WebGPU a whirl with
my C++ mini-3D-framework
([http://www.github.com/floooh/oryol](http://www.github.com/floooh/oryol)),
would be interesting how the C/C++ code would differ from the Metal rendering
backend, and how performance compares to WebGL on one hand, and Metal / GL on
the other.

~~~
om2
I'm being a little generous to myselff with saying "we". I'm on the WebKit
team and I followed this project but I wasn't personally involved in
implementing it.

------
binarymax
Lots of negativity in this thread related to non-adoption of Vulcan. But we've
been waiting too long for generic compute and the sooner Apple leads something
to the browser for GPGPU then maybe it will get everyone else to finally act -
competing standard or not.

------
wnevets
As someone whos knows almost nothing about 3d graphics and its APIs, how does
Vulkan play into all of this? Why should this new API be used instead of
adding Vulkan's API to the browser?

~~~
corysama
This is intended to be WebVulkan|WebDX12|WebMetal with room for other possible
underlying implementations.

In general, Vulkan was not designed with the web in mind. For example:
Vulkan's design intentionally has a whole lot of undefined behavior. Instead
of strictly specifying what happens in all possible accidental cases, they
strictly specify what is defined and provide debug layers that help you
identify during development when you are unknowingly stepping into bizarro
land.

Also, I expect Vulkan was designed with the expectation of process-level
isolation being the end-all of security concerns. That's not sufficient for
single-process, multi-tab browsers.

~~~
JoshTriplett
> Also, I expect Vulkan was designed with the expectation of process-level
> isolation being the end-all of security concerns. That's not sufficient for
> single-process, multi-tab browsers.

Chrome has process isolation, and Firefox is developing process isolation
right now. I don't think it makes sense for a new technology stack to go out
of its way to support single-process multi-tab browsers.

~~~
pygy_
But even in chrome, several tabs can share the same process, which means that
information can be leaked, cross-tab.

~~~
saurik
You say "can", but unless you have a very small number of tabs, the correct
phrase is "many tabs share the same process". I am currently averaging 10 tabs
per process.

------
kin
The Safari API is severely lacking relative to Chrome/Firefox. It would be
great if Apple would spend some time getting Safari up to parity so devs can
create a more consistent user experience for their browser.

------
normalperson123
what a coincidence. just the other day i kind of stumbled across the situation
with apple and vulkan and was totally mystified. why would apple, who was a
supporter of vulkan, not implement drivers for it, and in effect block the
possibility for a universal webvulkan standard and all the glorious benefits
of it? lo there was a reason! i have to say that i think apple is being a
complete dunce. so they refuse to implement vulkan drivers, or even modern gl
drivers, and now their next move is to create yet another graphics api? the
success of which would depend on everyone else supporting it when apple
wouldnt support stuff? apple has enough money (tax dodgers) to support other
standards. they should probably do that and do it well before telling everyone
else what to do. /rant

------
greggman
This probably doesn't matter but one of the advantages of WebGL is it's just
OpenGL ES so porting to it is relatively simple.

On the other hand all the big engines already support multiple backends so
adding another for yet another API is probably not a problem

------
HelloNurse
The discussion about Apple not supporting Vulkan is irrelevant because the
point of this Webkit proposal is replacing WebGL 2 for web applications, not
replacing the sadly fragmented "real" GPU APIs for native applications.

As a WebGL replacement and as a 3D API in general, many details of the
proposal are strange.

>Since we were building on Apple platforms we picked the Metal Shading
Language.

Mature and portable technology...

>pipelineDescriptor.colorAttachments[0].pixelFormat = "BGRA8Unorm";

No enumerations? Are they going to validate strings?

>let vertexData = new Float32Array([ /* some data */ ]); >let vertexBuffer =
gpu.createBuffer(vertexData); >commandEncoder.setVertexBuffer(vertexBuffer, 0,
0);

No internal structure?

>commandEncoder.drawPrimitives("triangle", 0, 3);

One triangle? No index buffers?

I don't understand whether they are offering an insultingly dumbed down
overview of a rather complete (but presumably ugly) proof of concept
implementation or throwing around gratuitously WebGL-incompatible ideas to
dominate the standardization process.

~~~
om2
It's really hard to make the example complex enough for experts without
completely losing most people. This is deliberately a simple example.

The string thing is the way enums tend to be done in modern JS APIs. It's not
really a bottleneck but if it turned out to be, we'd go a different way.

------
socmag
First of all I'd agree with everyone that if any new Web 3D API should come to
fruition, it should be based on a Vulkan like state model.

That said, from what I read of the proposal there were some interesting and
useful ideas. So take those ideas and start going to the meetings to build
consensus with the open standards instead of trying to co-opt it (which is how
this comes off).

In addition, Apple might want to consider getting WebKit in line with the
existing web standards before throwing curve balls. Currently lagging way
behind in many areas, which means we have to do much more work for Webkit
based browsers than anything from Mozilla, Microsoft or Google, and support
for some features isn't even possible.

Don't mean to be a Debbie Downer, and I'm sure the team itself has good
intentions, but come on.. Like everyone says the last thing the world needs
right now is yet another proposal for a modern Web 3D. It will reset the
clock. Again!

------
bobajeff
So is this supposed to be like a WebVulkan?

~~~
suyash
No it's WebGPU like it shows in the code. Vulkan is a competing standard and
technology.

~~~
bobajeff
You misunderstand. I wasn't asking what it's called. I was asking if the idea
here is a Vulkan like API for the web.

~~~
suyash
I answered that in the second statement.

~~~
corysama
You were having too much fun being pedantic to answer the question. It is not
WebVulkan. It is "like a WebVulkan".

------
ctdonath
Any word from Carmack on this?

------
filmywap
Thanks for sharing this valuable information to our vision. You have posted a
trust worthy blog keep sharing. Nice article i was really impressed by seeing
<a href="[http://googlepc.org/filmywap-apk-
app-2017-android/">filmywap](http://googlepc.org/filmywap-apk-
app-2017-android/">filmywap) app</a> this article, it was very interesting and
it is very useful for me.

------
walterbell
Could this be adapted for graphics virtualization, e.g. allowing several VMs
to securely and performantly render 3D workloads on a single physical GPU?

~~~
xigency
If they were running a web browser...

------
intrasight
If Apple has like 4% of the OS market and seems to be abandoning the desktop,
why do we really care what Apple thinks?

~~~
MBCook
Because of the fact they helped usher in the modern web with WebKit and
they're the ones in charge of this very popular thing called iOS?

~~~
robert_foss
WebKit came from the Linux Open Source landscape. It was created withing KDE.

Re: iOS being popular; You're in a bubble, the iOS market share as of 2016Q3
is 12.5%.

~~~
MBCook
WebKit did start with KHTML as a base, but it was Apple (and later Google) who
brought it to prominence. When it was only KHTML it was a bit player.

As for market share, that's percent of devices sold. By web browsing it's
about 25%, and that doesn't include the possibly outsized influence it has due
to being so much more common at the top of the market.

------
deafcalculus
This is awesome. IMHO, reducing the complexity of resource management in the
app is the right way to go for a web API, and Metal is closer to what a web
API should be than Vulkan.

Porting an app from OpenGL to Metal is much easier than porting to Vulkan. A
naive port to Metal often performs better than the GL version, whereas getting
performance out of a Vulkan port is a lot harder [1]. So, I really hope the
proposed API will be a C-based API that can also serve as a middle layer on
top of Vulkan/D3D12 for lesser mortals like me in writing cross-platform
native apps.

[1] aras-p is a Unity dev:
[https://twitter.com/aras_p/status/628569113053528065](https://twitter.com/aras_p/status/628569113053528065)
and
[https://twitter.com/aras_p/status/628569238794543104](https://twitter.com/aras_p/status/628569238794543104)

------
ino
If this takes off, what are the chances it will spread out of the web and be
the new standard way we draw graphics, the new abstraction available almost
everywhere, the successor to OpenGL?

------
filmywap
[http://googlepc.org/filmywap-apk-
app-2017-android/](http://googlepc.org/filmywap-apk-app-2017-android/)

------
watertom
Apple can't even ship up to date desktop and laptop hardware, and own such a
small percentage of that market, it makes the proposal almost laughable.

------
swipecity
I'm new to this, but does it mean that Apple is preparing for some AR stuff ?
Thanks.

------
mbrookes
Hey Apple, how about developing your browsers to support modern web
technologies first?

~~~
proyb2
Isn't Safari Technical Preview supported 100% ES6?

[https://news.ycombinator.com/item?id=11708840](https://news.ycombinator.com/item?id=11708840)

~~~
saurik
Apple definitely keeps up with core JavaScript and CSS support, but
essentially anywhere the web undermines their attempt to maintain control over
a protocol, file format, or API--or for anything that makes the browser
fundamentally more powerful (which undermines their attempt to get developers
to focus on native applications, and which stuff like ES6 is fundamentally not
an example)--they invest only a token amount of effort at best and at worst
they seem to actively cause more fragmentation (by pushing Safari-only
proprietary and sometimes even patent-encumbered alternatives).

~~~
paulddraper
Have you examples?

~~~
saurik
Service Workers, Pointer Events, Web Notifications, WebRTC... I could probably
go on, but these are the ones everyone generally has at the top of their heads
and which I can just rattle off without thinking about it much (and which have
already been mentioned by other people on this very threads, and so absolutely
should not require listing :/). The story of IndexedDB vs WebSQL (with Safari
developers apparently being extreme zealots for the latter and essentially
refusing to implement the former for years) is another great example. I
recommend doing some basic searches using Google, as there is _tons_ of great
commentary on how Safari is "the new IE6" or is simply holding back the web.

~~~
paulddraper
Firefox was just the opposite on Indexed DB/WebSQL. History written by the
victors.

~~~
saurik
WebSQL was never going to be picked up by Microsoft either: it was a WebKit-
only concept that was doomed from the start.

~~~
paulddraper
Opera might disagree.

~~~
xxs
Opera is WebKit based, so your remark is not well placed.

------
amelius
> Apple proposes new web 3D graphics API

Which works only on one size of screen? :)

------
cfv
I think it's fine, if they can manage to polyfill this fucker.

Otherwise it's just an incompatible wart like the getUserMedia implementation
was for years, like webaudio still is, and like some of their latest hardware
ideas have been.

Polyfill first, engine bloat later

------
macawfish
Hey Apple, where's your Web Midi support at?

~~~
exodust
Wow, I never knew that was even a thing. The idea of turning a knob on my midi
controller and having the web app respond is very cool.

------
neom
Kicking and dragging on WebRTC, WebCL, Vulkan. Business interests much?

~~~
gcp
WebCL is dead AFAIK. None of the browser vendors is interested in it. They'd
rather have compute shaders from OpenGL 3.2 in WebGL.

Note that on desktop, OpenCL is dead for NVIDIA too (they've been stuck on 1.2
for ages, they removed their profiler, ...), and AMD's new stuff also dropped
OpenCL 2.0 support.

I like OpenCL but it doesn't look like it's going anywhere. The unified
compute+graphics APIs are king.

------
natvert
How about just implementing serviceworker first?

------
giridhar50
this might be interesting.

------
doggydogs94
Yet another fine API.

------
douche
Is it maybe time to step back and think about whether having a low-level 3D
graphics API in the browser makes any sense at all? I know, we _HAVE_ to run
every conceivable thing out of the browser and on Javascript possible. But
just maybe building native apps would be easier than trying to shoehorn an API
into browser specs, where not only will you have to deal with hardware
variations, there will be the inevitable incompatibilities between the
implementations by each browser vendor.

------
whyileft
That is a very deceptive way to put it.

[https://jakearchibald.github.io/isserviceworkerready/](https://jakearchibald.github.io/isserviceworkerready/)

Safari is intentionally crippled in several areas. Its very specific and
obvious. It is dishonest for you to at this point pretend Apple is going full
force for web standards while they are explicitly not implementing features
that are available everywhere else. And how those specific features line up
directly as features which allow web apps to compete with its native
application market.

Edit: To anyone seeing this down-voted. Apple employees typically down-vote
stuff like this so please do not take this being greyed as anything but
manufactured opinion.

~~~
Benjamin_Dobell
Wait... what? Deceptive... really? Come on now.

[http://caniuse.com/](http://caniuse.com/)

In terms of tracked features they're ahead of Edge with both their stable
release and in development (TP) builds.

Don't let your own prejudices distort reality.

~~~
whyileft
[http://caniuse.com/#feat=notifications](http://caniuse.com/#feat=notifications)

Every. single. other. browser. Including desktop Safari.

~~~
tinus_hn
Except all the mobile browsers. Which makes sense since nobody wants
notifications on their phone from a website.

~~~
detaro
> _Which makes sense since nobody wants notifications on their phone from a
> website._

When the alternative is installing an app just for some simple notifications I
temporarily want, hell yes I want that option. Let's hope PWAs get there and
the browser vendors figure out good UI to deal with them.

------
kappalavinod
Download pokemon gio hack here [http://techvinn.com/pokesniper-apk-app-
download/](http://techvinn.com/pokesniper-apk-app-download/)

------
kappalavinod
Great blog with very useful information provided
[http://techvinn.com/filmywap-download-2017/](http://techvinn.com/filmywap-
download-2017/)

------
botverse
101 mentions of Vulkan so far

------
dzhiurgis
So much more value would be created if iOS supported Android-style progressive
web applications...

------
hacktually
We don't need more new standards.

We need concise, clear and coherent code.

~~~
paulddraper
It doesn't matter how well-built your house is, if you build it on limestone
in a flood zone.

------
varenc
I'd rather Apple implement getUserMedia in Safari first.

Currently, it's not possible to access a user's microphone or webcam in Safari
(desktop and iOS). They're the major outlier when compared to other browser
vendors:
[http://caniuse.com/#search=getusermedia](http://caniuse.com/#search=getusermedia)

------
phkahler
I don't agree with this. The web does not need a 3D rendering API. If you
think "web apps" are an appropriate thing, then perhaps it makes sense.
Ignoring that, the web to me is still a way to view content and as such I can
see a use for having navigable 3D scenes, environments, or content, but the
rendering would be left to the browser much the way rendering HTML is left to
the browser. I really don't like the amount of code running in my browser and
see no need to add more.

~~~
monocasa
VRML (and most of the scene graph style 3D apis) died in the 90s for a reason.

------
ClassyJacket
"The major platform technologies in this space are Direct3D 12 from Microsoft,
Metal from Apple, and Vulkan from the Khronos Group. While these technologies
have similar design concepts, unfortunately none are available across all
platforms."

Vulkan isn't available on the Mac huh? Yeah Apple, and just who's fault is
that??

------
jgord
Now that Apple has all power and wealth, they arrogantly push an api nobody
wants, resulting in man-centuries of wasted effort and frustration .. instead
of listening to their users [ in this case developers ]

We have seen this before - fortunately no matter how much money they put
behind this bad idea, the internet is larger than apple, and open standard
apis and choice will eventually win.

I don't want an apple api, I don't want yet-another-kool-language-fad they
will drop in the next marketing cycle, I want old style javascript to run fast
and be standards compliant on mobile, including on iOS devices.

~~~
threeseed
And yet Apple is proposing creating a fast, open, standards complaint
Javascript API.

