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

APIs that will transform the Web in 2013

blog.alexmaccaw.com

Post reply on HN
Print view View original

101–108 of 108 posts

Re: APIs that will transform the Web in 2013

#101

Post by riffraff »

icebraining wrote: post #98
est wrote: post #89

Earlier quoted context omitted.

IE7 got rid of DirectAnimation, which is basically DirectX in IE, since IE4. And now there's WebGL. And other features like - DirectMusic (MIDI support) - VRML (which is basically SVG) - dHTML+TIME (animiation support) - page transition effects - render doc/ppt/xls in html - .htc as web components

VRML (which is basically SVG) Not really; VRML was a 3D modeling language, while SVG is for 2D images/animations.

I guess that was VML http://www.w3.org/TR/1998/NOTE-VML-19980513

Re: APIs that will transform the Web in 2013

#102

Post by pavel_lishin »

BadDesign wrote: post #97
pavel_lishin wrote: post #67

Earlier quoted context omitted.

> How much time it takes to install a different/newer browser? In a corporate environment? Anywhere from days to years.

Where the heck do you live? What "corporate environments" ? I work for several years as a software developer in the "corporate world" and I can install whatever the heck I want on my machine.

It's a bit different for software developers; we can easily and rightfully claim that we need to be able to control our machines.

For accountants, insurance adjusters, secretaries, lawyers, it may not be so simple.

Re: APIs that will transform the Web in 2013

#103

Post by Shamanmuni »

zobzu wrote: post #78

Chrome != the web. I'll take webapps that works in ANY browser over "webapps" that works with Chrome ONLY any day of the 2013 year. Embrace extend extinguish the web Google? Thanks but no thanks!

Google is proposing and very actively working in the WHATWG and both WebKit and V8 are open source. So you can easily access the specifications for these APIs and see how they implemented them. It's the absolute opposite of "the Microsoft way". They even hired Ian Hickson, who pretty much is the "web standards guy".

It's not Google's fault that the other browser vendors are not as fast as them. They will eventually catch up and we'll all have a better web. I'm really glad the situation has changed so much since the days of "IE 6 only" and later "we all have to wait for the slow learning kid, IE". For a web developer these days are truly exciting.

Re: APIs that will transform the Web in 2013

#104

Post by calpaterson »

zanny wrote: post #40
AdamTReineke wrote: post #30

Earlier quoted context omitted.

Write the code in ES6 and compile it to ES5, then use Modernizer or some equivalent to detect which runtime is supported by the client's browser and serve the appropriate script.

Or just ignore IE8 and assume the "revenue loss" from anyone running that browser not being able to navigate your site is worth the loss of headache. I always wonder why it is an assumption IE support is mandatory. As others in this thread have pointed out, Chrome / FF now have a combined 700 million and I'd assume between 50 - 70% of the browser marketshare. At some point, using backwards broken nonsense to support…

> Chrome / FF now have a combined 700 million and I'd assume between 50 - 70% of the browser marketshare

They have 55% and IE has 35%, but it's much worse than that in a lot of English-speaking countries (like the USA, where IE has 43%). Additionally, older (read: richer) demographics are more likely to use IE than average. So are workplaces (read: corporate customers). IE support being mandatory isn't an "assumption" it's basically a fact. If you're writing for the public web, you probably have to support IE8, and if you're selling things or have corporate customers, it gets even more important.

http://gs.statcounter.com/#browser-ww-monthly-201110-201210-...

Re: APIs that will transform the Web in 2013

#105

Post by awj »

skyhook_mockups wrote: post #71
awj wrote: post #58

Earlier quoted context omitted.

> Oh and for those who can't or don't know how to upgrade away from IE7-10 there's ChromeFrame. That covers the remaining portion of the web. Most people who can't or don't know how to upgrade away from IE7-10 won't be able to manage installing a plugin either. That aside, I don't consider a beta plugin to be an acceptable answer to this question in any context.

As my original post said this all applies to web applications . If you're building a consumer facing brochure site then you neither want nor need most of these new web features. Have you actually used or tried to deploy ChromeFrame? Its plenty ready for prime time, and features: 1. A 60sec installation 2. No browser restart required 3. No admin rights necessary 4. IE6+ 5. Autoupdate just like regular chrome Even the…

> Have you actually used or tried to deploy ChromeFrame?

I'll admit, I haven't. That feature list is mighty impressive and all kinds of commendable.

That said, it still fundamentally is requiring people to install something on their machine. This is a difficult thing to do with the uneducated and often outright forbidden in the corporate world, so the two key demographics here are also the two least likely to use ChromeFrame.

Re: APIs that will transform the Web in 2013

#106

Post by bcoates »

azakai wrote: post #69
bcoates wrote: post #65

Earlier quoted context omitted.

Isn't WebGL still a disaster that bears an uncanny resemblance to a C .h file mechanically transformed into a browser API?

No, not by any reasonable account.

http://www.khronos.org/files/webgl/webgl-reference-card-1_0.... http://www.khronos.org/files/opengles3-quick-reference-card....

Look at the sources to http://media.tojicode.com/q3bsp/

Notice the clunky transitions between Javascript and some degenerate form of C where everything is a member function of some hairy stateful singleton global object.

Oh, and all that matrix math isn't part of WebGL, the API neither provides graphics-specific utility functions nor general-purpose math operations. You have to roll it yourself in Javascript. You know, the way you have to write your own layout engine to write a 2d webpage?

This is all before we even get to the shader, where they just threw up their hands and said, "fuck it, let's have them send GLSL source as a wire protocol"

Also, security problems, weird device whitelist/blacklist, Microsoft's reasonable "hell no" stance, etc. Taking WebGL seriously is sucking the air out of the room and preventing progress on satisfying the demand for sane 3d on the web.

Re: APIs that will transform the Web in 2013

#107

Post by zobzu »

Shamanmuni wrote: post #103
zobzu wrote: post #78

Chrome != the web. I'll take webapps that works in ANY browser over "webapps" that works with Chrome ONLY any day of the 2013 year. Embrace extend extinguish the web Google? Thanks but no thanks!

Google is proposing and very actively working in the WHATWG and both WebKit and V8 are open source. So you can easily access the specifications for these APIs and see how they implemented them. It's the absolute opposite of "the Microsoft way". They even hired Ian Hickson, who pretty much is the "web standards guy". It's not Google's fault that the other browser vendors are not as fast as them. They will eventually c…

they're not standard APIs, they're Google's API. Having an open source product doesn't mean the process is open, or the APIs are standardized.

The reason why they're not standardized and that nobody pushes for a standard too is simple. Most of them are very much tied to Chrome itself, instead of being tied to features, and have no sense being used by another browser.

This looks like a much more sane API: https://wiki.mozilla.org/WebAPI

Incidentally, it comes from the guys who actually changed the "IE 6 only" to what it is today, incl. the chrome dominance that resulted from it...

Re: APIs that will transform the Web in 2013

#108

Post by tjholowaychuk »

paulirish wrote: post #81
dreamdu5t wrote: post #62

Earlier quoted context omitted.

Agreed. It's frightening to see people embrace web components while completely ignoring the usability issues, and adopting the attitude of "develop first, think about API design later."

The folks behind web components are super open to feedback. I'd be happy to introduce you so you can provide some feedback on where the spec should go to better address the pain points you have.

Do you know how they'll tie into ES6 modules? (if at all), that's definitely a big concern for me, I'd like to never see a global again as far as libraries go. Anyway yeah that would be great! I totally understand the end goal of having something usable out of the box, I'm just not 100% convinced browsers can even really get away with that. There's still fundamental issues like dependency mapping and manifests etc that are purely user-land anyway, so at the end of the day they wouldn't really be useful without some sort of registry/packaging mechanism anyway
Post reply on HN