APIs that will transform the Web in 2013(blog.alexmaccaw.com)
blog.alexmaccaw.com
APIs that will transform the Web in 2013
http://blog.alexmaccaw.com/the-next-web
22 comments
Except IE's filters were an unrelated proprietary technology with an ugly syntax:
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
filter: blur(2px);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/
http://hsivonen.iki.fi/almost-precedent/
There is a reason why WHATWG considers HTML a living standard.
There is a reason why WHATWG considers HTML a living standard.
Sure, but IE screwed up more things than it got right. Way more.
And IE10 got rid of them:
http://blogs.msdn.com/b/ie/archive/2012/06/04/legacy-dx-filt...
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
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.
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
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.
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.
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.
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.
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.
It doesn't subtract from your point, but both iOS and Android do in fact have native-quality browser accelerometer support.
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.
Conveniently, you can still run them using desktop Chrome. Should be handy for development.
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.
edit: nevermind, I somehow managed to confuse it with Chrome Web Store.
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?
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.
A user-base of 350 million people, and Google's backing :)
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.
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.
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.
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.
> 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.
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 webapplications. 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 most technophobic user can follow 2 links to be able to use an app they really want to use.
And remember this is all about applications, not your average brochure site.
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 most technophobic user can follow 2 links to be able to use an app they really want to use.
And remember this is all about applications, not your average brochure site.
> 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.
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.
What proportion of web applications are funded by large companies? Obviously in terms of actual users, there's always going to be far more consumers than corporate users, but in terms of dollars-per-user? Any large company will have a large number of internal, normally web based, tools for all sorts of things - training, asset management, expenses, travel booking - and the amount of money that the company will pay for these tools will always be higher on a per-user basis than either adverts or consumer payments would bring in. Certainly sites with almost no broad corporate use - social networks and the like - will have fairly insignificant IE use, but corporate facing web applications will see broad IE use.
ChromeFrame is great, but it is probably against the usage policies of a lot of companies. Even if it isn't, most people are fairly wary of installing something on their company machine. You'd need the IT department on side to get broad deployment.
ChromeFrame is great, but it is probably against the usage policies of a lot of companies. Even if it isn't, most people are fairly wary of installing something on their company machine. You'd need the IT department on side to get broad deployment.
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.
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.
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.
Unless you have customers requiring the same web site works the same way in IE as well.
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.
So what?! How much time it takes to install a different/newer browser? I tell you - less than a minute. There.
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.
I definitely agree (to a point...I don't test with IE6 or IE7 anymore unless budget and time is specifically allocated for them), but "make sure your product works for as many people as reasonably possible" is not to be confused with "make sure your product works the same for as many people as reasonably possible".
I'm happy to serve static images to older browsers with an unintrusive note telling them what they're missing and how they can get it.
I'm happy to serve static images to older browsers with an unintrusive note telling them what they're missing and how they can get it.
Oh I agree that graceful degradation is a very viable option for older browsers.
"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."
I totally disagree. Why it should be my job? Do you want to use my product? Then use the right environment where my product works as it should, otherwise GTFO.
I don't want my product be used by incompetent users. Its 2012, people ought to be educated about technology.
I totally disagree. Why it should be my job? Do you want to use my product? Then use the right environment where my product works as it should, otherwise GTFO.
I don't want my product be used by incompetent users. Its 2012, people ought to be educated about technology.
> How much time it takes to install a different/newer browser?
In a corporate environment? Anywhere from days to years.
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.
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.
For accountants, insurance adjusters, secretaries, lawyers, it may not be so simple.
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.
"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.
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.
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.
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.
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.
Quick, anyone know when Windows 9 comes out?
Possibly never. The next version is near, though: http://www.theverge.com/2012/11/28/3693368/windows-blue-upda....
"Predicting the future" is a negative-click signal for me.
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.
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.
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://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...
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
Warning: It may shatter (or confirm) your preconceptions quite strongly
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.
Thanks for the link, very interesting stuff.
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...
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.
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.
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
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
Hard to see how ECMAScript 6 will transform the internet when everyone writing Javascript for the public web still has to support IE8.
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 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.
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.
> 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-...
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-...
> 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.
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.
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.
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.
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.
It's because IE combined versions has around 50% market share.
You are forgetting webRTC.
(peer 2 peer data connections)
(peer 2 peer data connections)
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.
why do you say that? several groups looking to replace flash with webrtc based video chat (opentok) and they already have some basic support.
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.
You can build p2p video, audio, multicast, real-time notification, etc. wrapped in a industrial level message channel.
No mention of Web Intent API?
This is cool. I didn't realize this was coming out of the Android camp and into general use.
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.
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.
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)
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.
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.
my thoughts exactly: http://jordanwallwork.co.uk/2012/11/my-most-anticipated-upco...
Reading the title I thought this was about REST APIs. I was wrong.
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.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?
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?
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).
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.
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.
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.
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!
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.
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.
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...
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...
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.
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.
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.
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.
the 2 best new E6 features for me: yield and default params -- finally :)
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.
Proxies are really interesting - think about how knockout.js syntax might change if it could hook directly into property changes on regular objects.
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.
the yield keyword is going to be very cool
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.
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.
agreed! generators will be nice
Uh, where's WebRTC?
Surprised Stripe isn't on here ;)
not that kind of API
Well, maybe. Alex works at Stripe. And wrote about having a browser API for payments.
http://blog.alexmaccaw.com/one-click-signups-and-purchasing
http://blog.alexmaccaw.com/one-click-signups-and-purchasing
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.
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.
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.
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.
lol, my favorite part was when you thought a totally hacked together, duck-typed, uncompiled language would produce less buggy code than Java!
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.
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.
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.
How do you feel they've done that?
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...