
APIs that will transform the Web in 2013 - olivercameron
http://blog.alexmaccaw.com/the-next-web
======
superasn

        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...](http://msdn.microsoft.com/en-
us/library/ms532849\(v=vs.85\).aspx)

~~~
timmclean
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);

~~~
yuhong
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?

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

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

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

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

~~~
InclinedPlane
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
Unless you have customers requiring the same web site works the same way in IE
as well.

~~~
InclinedPlane
Certainly, and that will always block _some_ web apps from adopting _some_ new
technologies. But is it going to block those new technologies from becoming
fairly popular even if they are not universal? I highly doubt it.

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

~~~
magicalist
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...](http://lists.w3.org/Archives/Public/public-
fx/2012JulSep/0074.html)

~~~
rurounijones
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

~~~
magicalist
It was a really poor showing, and not at all productive. Keep in mind, though,
that the mailing lists for the SVG and CSS working groups are open to the
public, so while it was bound to get contentious, the completely unhelpful
flaming was not coming from an actual member of those groups (at least not at
the start). If anyone is interested in participating in these kinds of
discussions, please keep in mind that reenacting your own take on Eternal
September is not helpful in any way. Acclimatize. Entrenchment and flame wars
only gets us html5 <video> and EcmaScript 4.

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

~~~
tjholowaychuk
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

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

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

~~~
chimeracoder
> I always wonder why it is an assumption IE support is mandatory.

Because for many, the _use_ of IE is mandatory.

Depending on what service we're talking about, a lot of the IE traffic is
going to come from people who work at companies that require the use of their
approved/installed software. Every time there's a post about IE there are few
people who come out of the woodwork to comment about how they only use Windows
+ IE at work, and then Firefox/Chrome at home, even on Hacker News of all
places. It's easy to forget on here that Windows still has the dominant market
share, and for many people who currently use IE (for even part of the day),
switching or upgrading is out of the question.

If you don't support IE, you're not encouraging these people to switch -
you're encouraging them not to use your service at all.

~~~
Jach
Depending on the service, it may be that they shouldn't use it while at work
in the first place. But that's an aside, there's a simple technical solution.
Every time there's a post about IE, and every time someone thinks (or believes
themselves to be an example that) there's a single person on the planet who
has to live with IE >= 6 when they don't want to, someone in the thread
mentions Chrome Frame.

~~~
untog
_Depending on the service, it may be that they shouldn't use it while at work
in the first place._

Sure. But if you run an online store it doesn't exactly benefit you to tell
people when they should shop with you and when they shouldn't. Supporting IE
may well mean higher sales.

------
vitno
You are forgetting webRTC.

(peer 2 peer data connections)

~~~
ianb
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
why do you say that? several groups looking to replace flash with webrtc based
video chat (opentok) and they already have some basic support.

------
fudged71
No mention of Web Intent API?

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

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

~~~
jQueryIsAwesome
It would be really cool, but the reality is that websites that uses similar
kind of data are usually direct competitors and work as closed gardens
(Facebook vs Google+, Vimeo vs Youtube, Bing vs Google). But I do hope that at
least multimedia tags will be able be dragged and accepted by other websites
(drag a video tag to YouTube, drag a pdf to dropbox, etc)

~~~
fudged71
Hmm, I see it as the opposite. Why _wouldn't_ Facebook want to register
themselves as a sharing output for images and text? They want us to share as
much as possible, and this would just make it easier for users.

Otherwise, you'd see sharing menus across the web with "Google+, Twitter,
etc." on them and no Facebook. Not a position I think they would want to be
in.

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

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

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

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

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

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

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

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

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

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

------
indiecore
the yield keyword is going to be very cool

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

------
drivebyacct2
Uh, where's WebRTC?

------
grinich
Surprised Stripe isn't on here ;)

~~~
hartleybrody
not that kind of API

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

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

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

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

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

