APIs that will transform the Web in 2013

http://blog.alexmaccaw.com/the-next-web

by olivercameron • 14 years ago

231 105 14 years ago

blog.alexmaccaw.com

indiecore• 14 years ago

the yield keyword is going to be very cool

kozmikyak• 14 years ago

Having very effectively used yield-like functionality in a few languages, I too am looking forward to it.

In Python it's allowed me to structure certain data-consuming and data-emitting functions in a way that makes both reading sense and storage-usage sense.

tjholowaychuk3• 14 years ago

agreed! generators will be nice

vitno• 14 years ago

You are forgetting webRTC.

(peer 2 peer data connections)

ianb3• 14 years ago

I think WebRTC is going to be more of a 2014 technology – it's still pretty raw as a technology, and even more so as implements, going into 2013.

hayksaakian• 14 years ago

why do you say that? several groups looking to replace flash with webrtc based video chat (opentok) and they already have some basic support.

est3• 14 years ago

I'd rather hope Chrome open API for its XMPP connection. Which is currently used for Chrome Sync.

You can build p2p video, audio, multicast, real-time notification, etc. wrapped in a industrial level message channel.

highwind• 14 years ago

Once thing I still have hard time understanding is Chrome App Store and Google Chrome Apps. I'm guessing it's something akin to Adobe Air, but has there been any success stories with Air? Also, I feel like Chrome App Store goes against the idea of open web.

bryanlarsen• 14 years ago

Besides Air, there was Mozilla's Prism/WebRunner/Chromeless, Fluid for OSX and several others. What advantage does Chrome Apps have other those previous failures?

maccman• 14 years ago

A user-base of 350 million people, and Google's backing :)

ianb3• 14 years ago

Mozilla's Prism/WebRunner/Chromeless are all basically defunct, and Chrome Apps aren't really the same as those anyway. Chrome Apps and Firefox OS Apps are basically the same – and in both cases it's adding some extra APIs that web pages can't normally get access too, and an optional packaging format, and a little application-related metadata. Firefox Apps are a bit more cross-platform, as they look a bit more like native apps on normal desktop systems and on Android.

jan_g• 14 years ago

Correct me if I'm wrong, but isn't Chrome App Store just a fancy collection of links to various websites that also supports user comments and rating?

edit: nevermind, I somehow managed to confuse it with Chrome Web Store.

jbigelow76• 14 years ago

I'm tempted to go make fake HN accounts just so I can come back and up vote this more.

I can understand, if not personally endorse, the need for "apps" on smart phones where access to functionality like the accelerometer is not available through APIs used to create browser based apps, but Google's insistence on trying to push app stores in the browser will just lead to pointless balkanization of the open web.

fudged714• 14 years ago

I see it as Google's way to lock people in to the Chrome ecosystem. And they have quite a bit of pull and opportunity because of Drive and Android.

I do see the benefit of some apps (I love Pocket and Clearly). But in terms of usability, I have seen issues that haven't been sorted out yet, such as the interaction with Chrome Sign-In (on public computers, the app start pages start up every time you sign in). And I do think this focus on browser app development takes away some of the effort that should be done on the web itself.

paulgb• 14 years ago

It doesn't subtract from your point, but both iOS and Android do in fact have native-quality browser accelerometer support.

skybrian• 14 years ago

It's the only way to make a "native" app on a Chromebook. As Chromebooks become more popular, these API's become more important (just like Android and iPhone API's).

Conveniently, you can still run them using desktop Chrome. Should be handy for development.

fudged714• 14 years ago

No mention of Web Intent API?

jordanwallwork• 14 years ago

my thoughts exactly: http://jordanwallwork.co.uk/2012/11/my-most-anticipated-upco...

purephase• 14 years ago

This is cool. I didn't realize this was coming out of the Android camp and into general use.

fudged714• 14 years ago

I was ecstatic when I'd first heard of it! The main draw I have towards Android rather than iOS is the ease of use of the interaction between apps. If the web can have the same benefit that I see on mobile, then there could be some explosively innovative interactions possible.

Web-to-web interactions right now are mostly just copy-paste and saving things to your desktop to upload again. It would be incredibly innovative to share more complex data structures between sites, like events, contacts, videos, etc.

czbond• 14 years ago

Great list - thanks. Finally .... no more callback hell. (yield)

  Vitno, thanks for the heads up on webRTC. I can see that having a dramatic impact too.

grinich2• 14 years ago

Surprised Stripe isn't on here ;)

hartleybrody• 14 years ago

not that kind of API

grinich2• 14 years ago

Well, maybe. Alex works at Stripe. And wrote about having a browser API for payments.

http://blog.alexmaccaw.com/one-click-signups-and-purchasing

kt9• 14 years ago

Reading the title I thought this was about REST APIs. I was wrong.

calpaterson2• 14 years ago

Hard to see how ECMAScript 6 will transform the internet when everyone writing Javascript for the public web still has to support IE8.

AdamTReineke• 14 years ago

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.

zanny• 14 years ago

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 outdated browsers becomes a financially unfriendly situation, especially when you can't reproduce a lot of the newer goodness (like html5 localstorage or websockets) in older versions of IE.

jfaucett• 14 years ago

the 2 best new E6 features for me: yield and default params -- finally :)

STRML• 14 years ago

Absolutely. Yield will transform node.js syntax, which is fantastic.

Proxies are really interesting - think about how knockout.js syntax might change if it could hook directly into property changes on regular objects.

lyaunzbe• 14 years ago

Even after ES6 comes out, how long do you think it will take for node to adapt it? I'd love to finally be able to use python style generators.

dotborg• 14 years ago

author didn't mention users at all.. maybe because they won't see any difference?

maybe except css filters, but we are yet to see webgl being used in production environment where mass audience is the target

those things are really cool from coder POV, but as an user.. sounds like increased CPU usage and nothing else.

tjholowaychuk3• 14 years ago

web components are still very flawed, they completely ignore a slew of problems, and still promote tons of global variables which is just a major no no. Some of the features that come along with the web component spec are fantastic, but the way they're doing it is quite wrong IMO, and it cant really be done right from a browser point of view really, the bulk of this should still be user-land, I find it a little scary that browser vendors are already "accepting" these sort of half-complete concepts as what's coming next, we dont need more broken tools

dreamdu5t• 14 years ago

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

paulirish• 14 years ago

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.

st0p• 14 years ago

None of this will work in IE7, IE8, IE9 or IE10. This will transform absolutely nothing on the web for many years to come.

I can understand people getting hyped up about cool new tech like this, but the article has way too much hyperbole to take any of it seriously.

rhizome• 14 years ago

"Predicting the future" is a negative-click signal for me.

nicholassmith• 14 years ago

If people work it so there's graceful degradation then it'll transform plenty of things for a large segment of the internet using public. Disparity isn't great but if there's developers pushing features out for the other main browsers it'll hopefully light a fire under the IE team.

BadDesign3• 14 years ago

So what?! How much time it takes to install a different/newer browser? I tell you - less than a minute. There.

abk2• 14 years ago

You'd be surprised by how many people won't do that. In my opinion, it's your job as a designer / developer to make sure your product works for as many people as reasonably possible, and not expect users to jump through hoops (no matter how small) to use it.

pavel_lishin2• 14 years ago

> How much time it takes to install a different/newer browser?

In a corporate environment? Anywhere from days to years.

skyhook_mockups2• 14 years ago

the article has way too much hyperbole to take any of it seriously.

This statement is itself hyperbolic.

A lot of these advances are going to impact web applications. Sure if you're building a brochure site then you should probably stick to web technology circa 2000.

The article mentions 350MM chrome users, FF has about the same market share. That makes close of 3/4 of a billion web users who will automatically receive the updates that allow app developers to target these new features. That's a lot of potential customers.

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.

In other words... no, the article is not hyperbolic and feel free to take all of it seriously.

awj2• 14 years ago

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

robryan• 14 years ago

IE should eventually support a lot of this also? IE10 has made some pretty big jumps. I guess they still haven't worked out having everyone on one version and automatically updating though.

bratsche• 14 years ago

Quick, anyone know when Windows 9 comes out?

kmfrk2• 14 years ago

Mobile is eating the world, and a lot of people, myself included, are using online instead of native apps. I have already cursed the gods for the horrible input type support across many browsers.

I think "doesn't work in IE" could turn into a problem, if certain web services won't work on IE Mobile. It might be the best incentive Microsoft has ever had to make step it up.

InclinedPlane2• 14 years ago

This isn't 2005 anymore, IE is becoming rapidly less relevant as time goes on. Other desktop browsers have been gaining marketshare and the most popular mobile devices do not use IE. Currently, IE marketshare is on a half-life of about 3.5 years, in another few years IE may even become inconsequential. In the meantime I think IE has lost its ability to prevent advancement of web technology merely by lagging on adoption. Indeed, I think the opposite trend may become true, where IE's lack of features which all the "cool kids" are using on cutting edge sites will drive IE usage even farther down.

pjmlp• 14 years ago

Unless you have customers requiring the same web site works the same way in IE as well.

leoedin2• 14 years ago

IE is so embedded in a lot of corporate machines that it will never simply go away. IE9 is good enough that in my experience even large users (like universities and large companies) are moving away from offering alternative browsers. Deploying only IE to thousands of machines is a lot easier than deploying Chrome or Firefox.

Consumer traffic may make the bulk of the web, but the actual financial contribution towards web development in terms of dollars-per-user is far, far greater for corporate traffic.

IE may be less relevant for consumer traffic, but it is just as relevant for corporate traffic. Given that corporate use is worth so much more financially, it won't go away. The IT department in a big company doesn't care what the cool kids are doing.

wiremine• 14 years ago

"This will transform absolutely nothing on the web for many years to come."

Yes, a better title would have been "5 APIs that will transform the Web in 2023" or maybe "5 APIs that will transform the Web in 2018" but that's not sexy enough.

However, I wouldn't dismiss it out of hand just because the timeline is sensational. The web is mature and huge, so any real, meaningful technological change is going to take decades at this point. That's a good thing, IMHO: the "browser wars" didn't really help anyone, user or developer.

drivebyacct2• 14 years ago

Uh, where's WebRTC?

transfire• 14 years ago

ES6 may well be the death of Javascript. They've managed to turn Javascript into Java, which means web programming is about to turn into a buggy nightmare.

scotth• 14 years ago

How do you feel they've done that?

taitems• 14 years ago

Even if what you're saying is true (which it isn't), it's completely optional. Don't want to use `let` scoping? Use `var` instead! etc.

bcoates3• 14 years ago

Languages don't work that way. Anyone touching the language has to deal with the whole thing.

Tooling ES6 code is more complicated, learning the language is much more complicated (it was nicely minimalist compared to other mainstream languages). At least they mostly stuck to mucking with the syntax--saying they turned it into Java is crazy until they introduce Java's broken threading.

ianb3• 14 years ago

It doesn't look anything like Java. There's a class statement, but it's not something dramatic, just some syntax around normal JS prototype patterns. The JS2 proposals years back started to look a lot more like Java, but those never went anywhere.

aneth4• 14 years ago

Seems to me that ES6 adds a lot of useful constructs.

Java is usually criticized for adding features too slowly and promoting bloated codebases due to an inflexible language. I don't see how this is anything like Javascript or promotes buggy programs.

danbeam• 14 years ago

lol, my favorite part was when you thought a totally hacked together, duck-typed, uncompiled language would produce less buggy code than Java!

superasn• 14 years ago

    CSS filters are already in Chrome and Safari, and allow advanced styling as as blurring, warping and modifying the color intensities of elements.

Isn't it funny that the first browser to implement these "filters" was IE 4.0 [1]. And at that time using any of these filters was a bit frowned upon and amateurish. Now suddenly everyone is gung-ho about it and calling it the API that will transform the web in 2013.

[1] http://msdn.microsoft.com/en-us/library/ms532849(v=vs.85).as...

timmclean• 14 years ago

Except IE's filters were an unrelated proprietary technology with an ugly syntax:

  filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);

compared to

  filter: blur(2px);

yuhong3• 14 years ago

Actually the first syntax was introduced in IE 5.5. The second is very similar to the IE4 syntax, so why not make it compatible?

ilink• 14 years ago

GLSL isn't exactly beautiful all the time...

est3• 14 years ago

You can always write this in IE.

    filter: Blur(pixelradius=2);

hfz• 14 years ago

Similar to how IE's box model was deemed incorrect until fast-forward today and people realized that their box model was simpler and easier to use compared to the standard. See: http://paulirish.com/2012/box-sizing-border-box-ftw/

yuhong3• 14 years ago

http://hsivonen.iki.fi/almost-precedent/

There is a reason why WHATWG considers HTML a living standard.

huhtenberg• 14 years ago

Sure, but IE screwed up more things than it got right. Way more.

yuhong3• 14 years ago

And IE10 got rid of them: http://blogs.msdn.com/b/ie/archive/2012/06/04/legacy-dx-filt...

est3• 14 years ago

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

louischatriot• 14 years ago

tldr version: http://tldr.io/tldrs/50b6a7a7bb22039977000ced

I enjoy writing client or server Javascript (yeah, really!), but some of these new features (such as generators) are something I very much look forward to.

angersock• 14 years ago

I think the funniest part of this is expecting web folks to write good GLSL code. That's going to be a laugh riot. Especially, since, you know, they can't make useful guarantees on things like available uniforms, varyings, samplers, etc.

azakai3• 14 years ago

1. First I heard about GLSL custom CSS filters. Is this on track to being standardized? I suspect Microsoft would never support it, for example.

2. Chrome Apps? What does that have to do with the web? It's a Chrome thing, not a web thing (those apps don't run anywhere else). I guess the author is a Chrome fan based on the end of the article though so that figures.

3. No WebRTC, and no WebGL? Perhaps ironic I mention it given my point #1, but these two are going to make huge strides in 2013, and their effects are much larger than nicer CSS filters.

bcoates3• 14 years ago

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

azakai3• 14 years ago

No, not by any reasonable account.

bzbarsky• 14 years ago

Yeah, it's amusing how the article talks about things that have been shipping in browsers other than Chrome for years (generators, say) and only talks about Chrome supporting them...

magicalist3• 14 years ago

To answer (1):

http://www.w3.org/TR/filter-effects/

I don't really see them making a large impact in 2013, but we may see them on by default in a shipping browser...we'll see.

Working group(s) discussion has been happening for quite a while now, though. Microsoft has indeed already stated that they would prefer not to specify the particular shading language that needs to be used. There was quite a long discussion on that point, as you can imagine:

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

rurounijones• 14 years ago

Wow that second link makes for some seriously entertaining reading. Recommended for anyone who hasn't seen an industry standards body forum before.

Warning: It may shatter (or confirm) your preconceptions quite strongly

azakai3• 14 years ago

Thanks for the link, very interesting stuff.

zobzu2• 14 years ago

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!

Shamanmuni• 14 years ago

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.

zobzu2• 14 years ago

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

Void_• 14 years ago

I'm a web developer, but keeping with these seems like a cat-laser scenario.

These APIs change every day, and knowing about them before they are usable in the wild feels like a waste of time and brain space.

Anybody feels the same way too?

olalonde• 14 years ago

Hopefully with Chrome and Firefox auto-upgrading in the background, browser compatibility will become less and less of an issue. Also, most of those APIs are decorative (like CSS filters) and shouldn't entirely destroy the experience for browsers that don't support them (it just won't look as good).

mcot2• 14 years ago

I think flexbox is bigger than any of those. The new spec is already in WebKit and the Firefox nightlys as well as Opera.

Advanced CSS layout is vitally important for creating web apps with the nice benefit of eliminating almost all extra markup that was used for layout.

APIs that will transform the Web in 2013

Related Stories