APIs that will transform the Web in 2013
blog.alexmaccaw.com
blog.alexmaccaw.com
CSS filters are already in Chrome and Safari, and allow advanced styling as as blurring, warping and modifying the color intensities of elements.
[1] http://msdn.microsoft.com/en-us/library/ms532849(v=vs.85).as...
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
filter: blur(2px); filter: Blur(pixelradius=2);There is a reason why WHATWG considers HTML a living standard.
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
Not really; VRML was a 3D modeling language, while SVG is for 2D images/animations.
edit: nevermind, I somehow managed to confuse it with Chrome Web Store.
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 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.
Conveniently, you can still run them using desktop Chrome. Should be handy for development.
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'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 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.
In a corporate environment? Anywhere from days to years.
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.
For accountants, insurance adjusters, secretaries, lawyers, it may not be so simple.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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...
Warning: It may shatter (or confirm) your preconceptions quite strongly
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.
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.
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.
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-...
(peer 2 peer data connections)
You can build p2p video, audio, multicast, real-time notification, etc. wrapped in a industrial level message channel.
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.
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.
Vitno, thanks for the heads up on webRTC. I can see that having a dramatic impact 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?
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'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!
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.
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...
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.
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.
Proxies are really interesting - think about how knockout.js syntax might change if it could hook directly into property changes on regular objects.
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.
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.
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.