Yes, my name is Faruk Ates, I’m a designer, developer and entrepreneur, I’m currently the co-founder of a startup called Presentate, it’s a presentation software in the browser creation tool, sharing platform. Before this I was a project designer at a startup called Apture, and before that I was an UI Engineer at Apple where I worked on Mobile Me and Online Store, and shortly after leaving Apple I created the JavaScript Library called Modernizr which is a feature detection library for HTML5 and CSS3 features and basically like all of them together all these new technologies being implemented in browsers and idea of the detection library is that you can use it in order to figure out when someone is using a modern browser, that they have sort of new cutting edge features available to them or not and then be sure code, your design, your styles of whether or not certain features are available and then make different experiences, so they can make sure that experience is always as good as possible for every user.
Feature Detection is a concept that is also being around much longer than Modernizr, but before Modernizr it was mainly used for detecting simple JavaScript features like DOM features and DOM methods were available in the browser or not and it was all pretty simple straight forward stuff, but when HTML5 and CSS3 start to coming around and becoming popular especially within mobile devices like the iPhone originally supported a lot of CSS3 features, but there was no good way of dealing with discrepancy between some browsers having support for these cool features that we want to use in other browsers not having support, and I always have been really strong advocate against user agentsniffing because it’s a unreliable practice, it’s a unreliable technique, it’s really hard to get it right, even when you get it right you are taking certain risk and assumptions that we shouldn’t have to take, that are too risky to use in a proper development environment.
I’ve always advocated against that, but when the CSS3 and HTML5 became really popular things and started to offer really greats options for us, like really great possibilities and opportunities, it really became clear to me that in order to us to take advantage of these features, we need to be able to tell the difference between one browser and another whether or not they have that feature implemented and not just whether that user agent is something that we sort of thing that we know supports that browser or that feature, but whether that browser actually has that feature build-in implemented and it works. So that’s were Modernizr kind of came about or came from, and I was trying to figure out how to tell the difference between certain browsers about CSS3 features and I knew I couldn’t rely on the user agent itself, because certain browsers would emulate or have the same user agent strings with only very minimal differences and yet have most of their features were similar except for like this one feature was not implemented or this other one, and yes, that is how Modernizr king of came about to really facilitate the process of developing and taking advantage of new HTML5 and CSS3 features without having to sacrifice experience for older browsers.
There is always some performance implications, but Modernizr it’s really fast, it’s really small, it’s really lightweight by design of course, since version 2.0 which we release last year, it’s possible for you to just build your own custom download of Modernizr using only the feature-detects that takes and that you absolutely need.
: Are like built the version that you….
A: You can build it and you can say: “I only need to test for this feature, and I only need to test for that feature, and I only need to test for these two other features from CSS” and the rest I don’t need, so you can just customize your download and only include that, so that your built is very small and lightweight and upgrade really fast and there is no performance implication for anything else, because you are not including it. Beyond that, even with a little performance implication and hit that you take, because Modernizr ideally runs in the head of the browser before the browser starts running stuff, because you want to know upfront whether or not your user it’s going to be able to see and do certain things.
So that it’s where we added the included yepnop library, which is also available stand alone, and we added that Modernizr.load so you can actually load different resources, different JavaScript and different CSS files based on certain features that are available. That way you can also really make sure that the experience for users is tailored towards being precisely what they need and what they are current browser or device is capable of rendering for them and capable of doing for them without you having to load any resources that the other don’t need or they don’t work on their device anyway, and that is for both CSS and JavaScript.
It’s been interesting, fun at times, frustrating in a lot of times. One of the biggest discoveries really and this was a necessarily news to us, but it was worse than anticipated, was that browsers lie a lot, they lie about a lot of things especially on mobile devices of the Android vendors, have a long history it’s far or less what is the problem right now which is really great, but they have a long history in the early days with the early versions of Android that every vendor would ship with their own custom Android browser and because they created their own hardware and they created their own software interface layer around it, they would often just take the stock Android code, the web kit engine, that was the mobile web kit engine, which works really well on the mobile devices, they would take that and just implemented and it will not necessarily correspond all of its implemented features with the actual output on the Android device.
And that is something that we found a lot in the early days where mobile devices would say: “Yes, we support this, we support that” but they wouldn’t actually render it, the engine would say that they support it because they took the stock web kit from a sort of point in the development process in which the engine has to implement it but the graphics engine that is hooked up to it is not. We’ve seen that on the desktops as well but far or less in our days, now days it’s much more about certain HTML features which have their API’s exposed to the browser because the vendor say Google for Chrome or Apple for Safari or Microsoft for IE or Mozilla for Firefox, to building these features to the browser but sometimes they keep them on the dev channel and they start implementing things before they are fully ready, but then you have people using those browsers and suddenly it’s like the engines says this API is available, but there is nothing hooked up to it yet and doesn’t actually do anything yet.
So that it’s a false positive, so we have that quite a lot and with the proliferation of mobile devices and different various sizes of mobile devices and all this different browsers running on them, false positives are our biggest sort of issue that we have to deal with, that it’s the one thing where we find it, browsers just lie a lot, they say that support something and then they don’t actually support it yet. So that is the main thing.
It’s being mixed-bag., some have been like really well designed, others have been really poor designed and some just have been designed and replace and design several times like CSS gradient had 4 or 5 different variations of the syntax and how it would works exactly and that makes really hard for developers to use them, because we have to do it all these various different implementation and we want to support different browsers, which that is the feature purpose of adding new features and technologies. But we still have to do it in 5 different ways, it defeats the purpose of the standardization process.
But others have been perfectly fine in their implementation, personally my biggest issue, in my observation of the biggest issue in general is a lot of the API design it’s not very intuitive, it’s not very easy to use sometimes as developers sometimes really difficult to figure out how to actually use a certain feature properly, and at other time from a design perspective features are implemented with default UI chrome like default visuals for their implementation, which we as web developer or web designer cannot change and we are stuck with like if we want to use this new feature then we have this really awful UI for it that doesn’t fit it with the designer for site at all and really stands out being very different and in many cases just ugly. People are forced to still recreate that feature anyway even if the browser now has it implemented just because we cannot change the look in few of it.
6. Rules mess with CSS, vendors specific CSS rules?
Specifically it’s features like the new HTML5 input attributes like color and date, this date are sort just terrible in almost every browser and they just look really out of place no matter what the design of your site is, so it’s an awkward experience and if you want to have to get experience you basically cannot use these new HTML5 input forms even there are better and offer a better accessibility and offer better integration with OS and it’s great for users from that sense except that from a visual sense it doesn’t fit within the designers so it’s really hard to actually get that done and implemented.
I think it’s great that are other rapids cycle of development, that is something that we’ve been really sorely missing and the 2000’s like especially the early 2000, we just saw very little active development happen on the web as a technology platform for many years in a row, and that really hurt the web because without that active development we are not going to get the features that we have in better shape, we are not going to have more new and exciting features that we really want.
Especially when you compare to the native platforms from Apple and Microsoft and Android, there are a lot of stuff that you can do on those devices when you build a native app, you can use the camera fo rall sort of cool ways you can use accelerometers, all this device API’s that are really great that then we’ve love to have access to, are just not available on the web within the browser. Some of them are now are finally being implemented in browsers but it’s still a really long way off before we get to feature parity and even by the time we get to feature parity of what the native platform should doing now, it will take another couple more years before we get to the point where they are by then. So the rapid development cycle of the technology in browsers is really great because it also allows browser vendors to catch up to the native platforms faster, because the native platforms tend to have a really cycle that is much slower.
Apple’s iOS tends to only like have a yearly really cycle of major updates, like major new API’s, major new features in the whole system. Android works a lot faster but it’s a lot more fragmented and doesn’t have the same kind of installed base that upgrades quickly unlike Apple. So in that sense it’s great that we have, it’s not great that we are pretty far behind on the web, but it’s great that we have such a frequency rapid upgrade cycle where competition it’s really hard, really fearce right now with browser vendors, several of them having on over to a 6 weeks release cycle of their browser, which is great. The ones that don’t, are the ones that are really lagging behind and losing market chair because if you are seeing one browser constantly updating itself and adding a new features and the browser that you are currently using just doesn’t change for really long time and you as user will have more incentive to change.
And I think this is how competition works and this is how should work, so in that sense it’s really great to see this really rapid cycle in terms of the output of it however, we still frequently see that issue of false positive where browser vendors try to rush new features out and try to get everything implemented really fast, but the main problem that I’m seeing and I don’t know how vastly this spreads across the platform as a hole, but the main problem that I’m seeing is the stability of rendering, is actually really poor sometimes, but we are using these new features, we see a lot of like glitches in the rendering when the software and the hardware accelerated graphics renderers at toggle, so when we start using a certain feature in CSS and it kicks in the hardware accelerator for rendering that feature.
Then sometimes we see little glitch happened in the page and just sort of animations will leave all these artifacts across the page all the time in certain browsers and that it’s kind of stuff that is now starting to fall through the cracks a lot more because the browser vendors are iterating so much faster, are not doing QA as effectively anymore and when they implement a new feature is sort of run through all the typical test but it’s not robust enough yet, and now all these features are added and it’s great and we can use them, but in return for that pace of developments we also have a lot more issues to deal with in terms of the final details of the implementations and the robustness of the implementations. That is a really big problem right now.
It’s hard to say, I’ve kind of hard to predict where things will go exactly in the space because I think a much bigger problem is that there is so much available for the developers that it’s hard to get into web development right now, if you are just starting out it’s really hard to find your starting point and once you have that it’s really hard to move on from that really early beginning point. Because there are so many options, too many options, if you want to build an app here are 50 JavaScript environments and extra language processors and different sort of runtimes that you can build it, here is 25 frameworks you can use, each of them does something slightly different than the other and approaches is different across all of them, and some of them works together and some not works together, and then all these little glue libraries between everything to say: “Ok, this is small little utility that only does this, this is small utility that only does that”, but in order to actually know what the best way is or what the best technology stack is for your particular problem, there is really no good way of figuring that out without just spending huge amount of time and effort on researching all of these different libraries and tools and languages and preprocessors to see whether or not something is suitable for your current project.
But on the other hand it’s great that we have the opportunity to have very specifically tailored libraries and utilities for every particular need, which you know the needs of people are extremely diverse and many. In terms of what we’ll see, I think the performance aspect is something that is very key, right now especially on mobiles, we are seeing performance still a big issue specifically for apps. If we are doing web apps inside the browser and things like CoffeeScript have a tendency to not even work all that fast on the desktop compare to just to raw JavaScript or slightly pure JavaScript or JavaScript both only like jQuery or Zepto as the only library that they use. The performance angle something that people overlook a little bit and they go like: “I much prefer CoffeeScript because of x is clean or syntax”, there is perfectly valid arguments for that but then something that they’ve chosen may not actually perform as well and if there is something that runs in the browser on the client site it can actually be really big performance issue for people on older devices where all the computers are older, mobile devices and that is something that we don’t tend to test against a lot and that is a problem that we should be more vigilant about, I think has in industry.
Tools, I think the technology and the API’s, the CSS3 and the HTML5 all these features, the ones that are being implemented are for the most part really great and may feel that some of them should have better API’s, it’s partly my own fault for not trying to contribute and participate in those discussions more, but that is also a really difficult process, it’s really hard to get involved in that because you really have to spend essentially your entire day, every day for weeks and even months and arguing about this and discussing the pros and cons, making your case just for a certain feature to work a little bit better and if you are not going to be paid for that, then that is even harder. From that sense, that is something that I feels missing is more collaboration from the people who make and design websites into the process of designing API’s that they have to use. But overall, the API’s are pretty good on their own but they are not a full product, they are really just individual technologies stacks that are available to be used but we don’t yet have the tools to really use them.
The thing that I feel is most missing is more mature tools for developing and designing for the web. There is no design tool in the browser that is really useful for designing and quick and simple websites or even slightly more complex websites if you spend more time on it that actually designs properly for the web, that is in the browser and that helps you create more accessible semantic pages that also happen to look really great and aren’t coded by hand entirely from scratch. Debugging and resource management on the web is something that is still really painful and really cumbersome especially if you compare to Apple’s developing platforms where there is so many fantastic tools there that app developers can use in Cocoa and Objective C for debugging their apps and we have nothing like that on the web, we have nothing that allows us to see like: “Hey, this is my JavaScript Library and this is my Web App” and accurately figure out where are memory management has issues and how we can actually deal with that and how we can unload memory effectively and efficiently in JavaScript so we can say like: “Hey, we have these great high resolution photos that we are using”.
But the users are now in this part of the app, we don’t need all this anymore and Garbage Collection allows us to sort of like just take those out of the DOM and dismissed them and destroy them, and then Garbage Collection will come in and re-clean that memory, but what it means is that we are completely dependent on the browsers being smart about that and what we are seeing is that sometimes you are not smart enough and we can either way for browsers vendors to create smart algorithms and becomes much efficient about collecting that memory back and doing Garbage Collection and all that. The other option will be for us to have better tools and access to manage the memory of all these resources in our page. And that is something that I think the web as a platform, it’s very far behind the native platforms right now.
I’m personally much more fan of trying not to use pollyfills and shims and instead give Tiered experiences, so create something that is as close as possible to what you really want to offer to user based on whatever features are actually available in their browser, if they don’t support certain features that give them a slightly less rich or slightly less visually pleasing experience, and uses features that the browsers are if that particular browser does have them and enhance experience even further. A big example that is like CSS gradients and border-radius, IE users are not going to care if that box is square or if it has run the corners, so there is always pollyfills that are trying to recreate around the corners in IE, all these techniques with CSS that requires extra markup and all that, it doesn’t matter.
If that around the corner is that important to the content then probably should be an image or something like that, should be real content and a lot of pollyfills they try to make it easy for us to offer one cookie of experience to a larger majority of users without having to worry about this, but I think the time we spend on creating them, on implementing them and on testing them, good just as well been spend on this creating slightly less awesome experience for the users that don’t have support for certain feature. I also thing that is a better mentality or better mindset to have when designing these products for the web, because the problem with pollyfills is that they add a lot of extra JavaScript overhead to implement the feature that the browsers doesn’t understand yet and the more you do that, the worse you actually make the experience for people on older devices and older browsers because their JavaScript engines are really significantly slower than the once who have the feature implemented natively, and as a result now you’ve actually made their experience even way slower than already was and certainly slower that it had to be and speed is really the best and the most important feature that you can have in your website or web application.
So if you are creating something that looks great but your users on older devices and older browsers are seeing it only because that is a lot of pollyfills simulating features and emulating these features and enhancing in that way, there is a good chance that they are actually waiting many seconds for the page to be done and ready for them to interact with, and when they do interact with it it’s really slow and not responsive. So that is actually really much worst experience and that is why I feel like people kind of go overboard with pollyfills, say they have a tendency and just libraries and plugins in general, like people have a tendency just throw everything together and start using it because this is a tool that takes care of the need that I have.
So they just sort of mindlessly throw it in there and start using it, but what we can see is sometimes they develop these websites with 30, 40 maybe even 50 different JavaScript files being included in the page and all these tiny little files and little utilities, and little libraries and for the most part they didn’t need all that or they didn’t need it on every page but certainly would need it on their every circumstances and they could of recreate the effect of those things with just some significant but with some manual efforts to just take the good parts of it and apply them a little bit more sensibly and be a little bit more efficient about the code, the size of the code and the overhead, the performance overhead of the code that are now using. And that is something that we see a lot where people just overuse pollyfills, and overuse libraries, and overuse utilities, which really can hamper the user experience a lot, and that is the thing that matter most if a website or an app is just fast, is responsive, doesn’t force to use it to wait for a long time and it’s all about the function. It’s great if it looks great but if it’s too slow to use people will just not use it and if it doesn’t offer functionality for them, people would just not use it, so I think a lot of developers have their priorities a little bit run sometimes.
Dio: Thank you very much Faruk!
Thank you!