Hacker News new | past | comments | ask | show | jobs | submit login

Credit to Microsoft for reversing their previous stance on WebGL.

Credit to Mozilla for pushing 3d on the web and forcing the issue. Any browser that doesn't implement WebGL will soon be considered crippled; Microsoft desperately wants to avoid that title again, so in a way, Mozilla forced their hand.

Competition at work.




memorable quote from http://john.jubjubs.net/2011/09/15/mike-shaver-thanks/

"And [Mozilla's Mike Shaver] affected my framing of the problem deeply – I remember one day a couple of years back when we were talking about some market share point, thinking about how incredibly, insanely competitive the browser technology landscape was – and he said to me: “Look, this is the world we wanted. And this is the world we made.” Wow. Exactly right. He taught me so much about how enormous an impact a group of dedicated people can make."


Thanks for the link.

I've bumped into Mike a few times at Facebook; he's one of the most knowledgeable people I've ever met.


"Any browser that doesn't implement WebGL will soon be considered crippled"

Really? I don't think WebGL is that important. What's it really good for besides laggy browser games? What's with the hype on browser games anyway? They're always going to perform much slower than native code. I don't see WebGL becoming such a critical aspect of browsing that the average user would consider IE "crippled" for not supporting it.


Your challenge, should you choose to accept it, is to dream up an amazing and popular application of WebGL, now that a majority of web browsers will be supporting it. It might not be a game. Warning: imagination required.


It's hard to dream big about the browsers getting the modern iteration of something we've had in some form since 1992.


How does that not apply to every single thing on the web, whether text, image, animation, video, or interaction?


You are assuming that a delivery mechanism can't be transformative.


ASM is only 2x slower than native (it was 10x prior to) and will be 1.5 soon. With a way better distribution model. Have you seen UE3 or UE4 demos?


>ASM is only 2x slower than native

Only in wilfully misleading benchmarks. Allow use of SIMD and multithreading and asm.js can be as much as 50 times slower:

http://cdn.arstechnica.net/wp-content/uploads/2013/05/native...

http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...


Good point: re multithreading. I wonder if web workers could be used to resolve that?


Here's one application: http://youtu.be/zB7QEFCR1Zk?t=16m59s


It will soon be used for numerous business apps as companies are porting their native applications to work on browsers.


I just hope the desktop versions don't go away.


I am surprised they didnt try to push a webdx based off directx.


They did, sort of[1], it didn't appear to fly.

[1] http://lists.w3.org/Archives/Public/public-fx/2012JulSep/007...


I dunno... Allowing the language to be selected like a video codec or image file format seems like a reasonable request.

There are three issues:

1) Language pluggable?

2) Spec-ed shader languages

3) Mandatory languages

The proposal was:

1) No

2 & 3) GL SL ES

Microsoft proposed:

1) Yes

2) GL SL ES

3) None

The perfectly reasonable compromise would have been:

1) Yes

2 & 3) GL SL ES


It may sound reasonable, but ultimately is against the universal spirit of the web, and thus should not be standardized. Your #1 should be No, because if it were Yes, we'd have a mess of mutually incompatible, vendor-specific, proprietary languages fragmenting 3D content on the web.


Mutually incompatible, vendor-specific, proprietary anything is an inevitability. #1 isn't about that. That's what #2 and #3 are about.

#1 is about planning for extensibility. Just look at the hackery with JS where lonely, otherwise ignored, strings are used for things like "use strict" and "use asm". Or where Microsoft added "conditional comments", which quite frankly, was essential to the development of Outlook Web Access, which basically gave us Ajax. Or all the absurd vendor prefixes on CSS tag names. Or one of 100 other little hacks that browser vendors have invented to try to innovate past the standard. Pushing pass the standard, by the way, is the only way forward. We've learned that lesson by now, so we should plan for extensibility.


OpenGL already has a mechanism for extensibility, and proprietary junk is only an inevitability if we allow it to be enshrined in open standards. There is no reason to accept proprietary DRM plugins in CDM, and there is no reason to accept proprietary shader languages.

The reasons are manifold, but here are a few:

- Standardizing non-standardness gives proprietary implementations an unwarranted air of legitimacy and blesses incompatibility.

- Proprietary plugins and extensions are more likely to have untested security vulnerabilities and widen the browser attack surface.

- Proprietary extensions violate the essential web principles of cross-platform compatibility, graceful degradation, progressive enhancement, and accessibility.


MS have done little to push the IE team around in recent years, thankfully.


Sounds great - theres so much talent locked away at Microsoft if only business models werent getting in the way.


Hopefully MS collaborates with other browser vendors in accommodating asm.js-optimized code, too.


Now let's see when mobile browsers start to support it. Probably 3 years from now for any meaningful support.


> Credit to Microsoft for reversing their previous stance on WebGL.

One cant believe anything MS says. And it's another proof of that.

Remember when WebGL wasnt "secure"? Strange , now it is.

I say bull* , like their bull Venture Capital sh*t.

But I guess they have enough spare change to do community management on HN ( ie propaganda ), looking at all the MS spin here.


Hey I slated their VC stuff (see my threads), but this is good news.

I wouldn't tar the entire organisation with the same brush.

There is hope yet!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: