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