 I feel excited. I feel like a pilot right now. Really. OK. I want to start by really saying that I'm really, really, really sorry if you're expecting accessibility talk. I didn't mean to break your hearts on Valentine's Day. And I'll quickly jump to my introduction. I am Sawik. I run a web design studio called Mirage in Delhi. We are just a two-person company. I am the fatter one, obviously, like last time as well. I want to start with a little bit of background here. 1999 was when I was, I got my first hands-on experience with HTML as a seventh grade student. Teacher taught us a few tags. We just did a couple of tags. A white screen with a few black text showed up. I wasn't like really excited until a friend introduced me to these two, where is it? Boy. Until a friend introduced me to the marquee and the blink tags. Right? I was excited like this thing moving around. And I was like, OK, this is so interesting. And those were also the days of I5 and Netscape, right? Those browsers used to do the rounds at that point of time. Here's a marquee and the blink tags. Now, I didn't know at that point of time that Tim Berners-Lee in about the year 1989, in that year, he had invented the web in a way. That was like 10 years before I had started my markup experience. And today it's approximately 25 years. Can you believe it? I wonder how has it managed to be around so long when technology changes so fast? Did anyone question this at any point of time? Any of you? Any Razor fans? None of you. I did probably very recently actually. And I think that it's because of some of the principles that the web has been built upon. And that's what I really feel. And I'll highlight one of them. And it's called the principle of least power. It is highlighted by Tim Berners-Lee. I'll quickly read it for you. He said that computer science spent the last 40 years making languages which were as powerful as possible. OK, the year is 1989. Although this article is published in 1999. Nowadays, we have to appreciate the reasons for picking the not the most powerful solution, but the least powerful one. Because the less powerful the language, the more you can do with the data stored in that language. So if you store a data in a proprietary powerful language, only an application made in those languages will be able to extract the data. If you store the data in HTML markup, almost any language will be able to parse it and take the data out, right? And another principle over here is that HTML is forward compatible. So it has a healthy fallback for any new tags that is going to come in. This has been built into the system. So you can introduce new tags as the day goes forward, as the years go forward. 25 years from the start, we have so many new tags today. And it all just works, right? HTML never complains. Now, as a result of all these principles, we have about 824 different ways to connect to the web right now. And about 7,000 kinds of web browsers that connect to the web. About 432,000 devices, types of devices that access the web. And about more than 1,000 different screen sizes that access the web today. Crazy numbers, right? Please don't quote me on these because I cooked them up right before this. But the point still stands, right? The point still stands that there are just too many devices, various kinds of things that have started connected to the internet, to the web, actually interfacing to the web at this point of time. And the web is everywhere right now. All devices have it. People are getting connected. Cars are getting connected. I don't know what new is going to come up. And in many ways, we are dependent on it. And so much so that someone made a meme. And he said Wi-Fi is more required than even food, water, shelter, and warmth, right? And when he said Wi-Fi, I'm sure he meant the web. He wanted to connect to the internet and he wanted to work, do something, right? And the clients are really fragmented today. There are so many different kinds of systems that interface to the web right now. And it's also a side effect of ubiquity of the web because it's there everywhere right now. But how do we deal with this? How do we deal with so many devices connected to the internet? How do we deal with so many different browsers connected to the internet? Well for a long time we have been following something known as graceful degradation, right? So what does it say? It simply says that I will take the best browser that I have at hand right now, right? I'll make the website on that. I test it. It works. Now let me just go to a older browser or a different browser and just check if it works or not. Yes, it works. There are two problems. Let me just fix them, right? Let me go to some other older version. Then two more problems. Let me fix that too. So we are patching our website after making the most, the best possible website right now to patching the thing for, to support older web browsers, right? That's how we have been doing for a long time. And we also used to love putting this. Like because we tested on this one, like that is the best possible browser at that time that we built for. So we put this because if you're not on this browser, probably we have not tested it on your browser so we can't guarantee it will work well or not. But what about today? What happens when things have changed today? Browser stack, there are businesses now that are giving you services of testing your websites on different browser. Browser stack has 300 plus browser versions. In 2011, 20 different kinds of, and more than 20 in fact, mobile browsers were present. And if you look at the rendering engine, there were four or five, plenty of them based on WebKit and different versions of WebKit. All the WebKits were also different. Like, so how long can we start doing, how long do we continue doing this that we make the website for our best preferred browser and then go back and check on the different devices, check on the older browsers. Does it work or not? And to what depth do we do it? Do we go back to one-year-old dated browser, two-year-old dated browser and things like that? How far can we do this? I also want to add over here that looks are really deceiving in this because the web is tolerant. You can make something look good, but that doesn't mean that under the hood it's also good. Also the fact, another question is, are we just catering to web browsers today? I don't think so. I think it's a little different because now there are a bunch of services that are trying to take your code and read your code. We consume the... So there are read it later services. There are many accessibility tools. Search what Google comes and indexes your page all the time. All these things are trying to use your code at this point of time. And there is this small piece of thing that is given on futurefriendlyweb.com. Disruption will only accelerate the quantity and the diversity of connected device, many of which we haven't imagined yet. It will explode as will the quality and the diversity of people around the world who use them. This is scary. I mean, do you agree with me? This is scary. Anyone? I should probably ask anyone who disagrees because no one is raising their hands. So everyone will automatically agree. Anyone who disagrees? Yeah, thank God. Thank you for agreeing with me. I also think that the fads will die and there will be new ones that will come up. Things like SEO was such a big thing sometime back and now suddenly people have realized, oh, my God, our code was not right. A new thing that right now is mobile is in. We are in the mobile era right now. We never saw it coming about five years back. That becomes a fad right now. And in 2003, there was a presentation given by Steve and Nick, titled Inclusive Web Design for the Future, in which they suggested a different method, an alternate to graceful degradation, which they named progressive enhancement. So what did they suggest? They said this, that you start with your content. Take your content. You mark it up in a standard semantic fashion. So you add HTML. After that, you add your style sheets around it and at the very end, you add the scripts around it. So they said that do it like this. So what is the advantage of doing something like this? That is what is the advantage of not mixing up at the content point with JavaScript and things like that, is that people who are on basic browser get the base experience. They'll just get the content in the markup. They'll probably not get CSS if it doesn't support CSS. Or if they don't get scripted, then support script. But if someone has a modern web browser, they'll get the entire stack and your website will run exactly the way that you want it to run on your modern web browsers. So that's progressive enhancement. And no one is excluded from this. No device, no browser, if you're following the HTML standards, you're not excluded from this. Does that make sense? That is the way it was suggested. And Christian Hellman, who was here with us about four, five months back at JSFOO, he has written an article in which he said that I'm always amazed about the lack of support for progressive enhancement on the web. Reminder again, 2003, this idea was proposed. Whenever you mention it, you face it a lot. You're like, yeah, but what do I do? And you feel that you have to defend something that should be integrated in the DNA of anyone who works on the web. So you're trying to, like, it just feels bad that right now I'm trying to defend something that I think every one of us should follow. Many of us probably do already follow. But the problem is that there are these things that come up, we know our customers. So I know what customer I'm serving, I know what exactly to write. No one uses that browser, so I don't care about that browser, right? Do you hear these things? We build enterprise apps, we know exactly what our enterprise customers need. But that's too much work. You want to go and dive into JavaScript straight away, but that's too much work. Move fast, break things. If you're breaking the web, I don't think that I'll agree with you. And one more thing is we make web apps. There was a little bit of mention previously also, I don't really agree that a web app is different from a website. A web app is a website, in my opinion. There isn't really in any way you can say that this is a web app and this is not in my opinion. One more point is who has JavaScript disabled anyway? So I can start with JavaScript straight away, right? And in fact, you know things are really, really bad when someone from among the top e-commerce companies, a designer, he tells me about six months back that relying on JavaScript is not a problem for us. Today, no one can complete an online transaction without JavaScript anyways. So why do I care of supporting a non-Java script thing? I think this is really bad position that we are in because I feel dependence on JavaScript is a mistake. And please don't think this. I beg your mercy if you think that you want to shoot me down. Just bear with me. Because yesterday I'd say it's something like that and all hell broke loose at the workshop. People just went right at me. What are you saying? All I'm saying is JavaScript can make your application a superhero, right? Superman also has legs. So he can walk. He doesn't need the cape always. Really progressive enhancement is more about dealing with technology failing than technology not being supported. It's not about JavaScript not being in the system. It's also about JavaScript failing. And therefore there is a way in which the user can still continue using your systems, right? And here's a local Bangalore boy who says that most bugs I deal with on a daily basis are caused by some JavaScript library breaking and randomly breaking up. And this is harsh reality. Christian Hellman also proposed a very nice analogy. He said you have elevators and you have escalators. If an elevator breaks, you can't do anything about it. If an escalator breaks, you can still use it as a staircase. It's such an amazing example. We want our software to become escalators and not elevators. I have a question was put up yesterday and someone said that are we not encouraging people to use old browsers by supporting absence of JavaScript? And I thought about it yesterday. I got very less time and this is what I've come up with. I think people don't use old browsers out of choice, right? Also, I think it is far more important for a website to fulfill its purpose rather than to remind a person, look, you are not using a new browser. I'll not let you use my system. You want to book a ticket? I'll not let you book it because you're using a old browser. I think that is bad. It's very important that you have set a promise. Your website has a promise. You fulfill that first. That is very important. So in July 2013, there was a lot of discussion about the relevance of progressive enhancement. And I read about that, all the discussion at that point in time. And I found that some people have inaccurate notions. And in fact, some of the good voices on the internet also found that. And people think that progressive enhancement is not about progressive enhancement is about making websites for a basic system. So it's not about that. It's about starting your website to run from a basic system to something that is as powerful as you can imagine. It's not about building a website for a basic system. Right? And no one is asking you not to use JavaScript. Please don't conclude that from this use JavaScript. All I'm saying is use progressive enhancement. That means your site should support a browser that only runs HTML or it runs HTML and CSS or it runs all three of them support all of them. Brad force adds that there's a difference between support and optimization. So support means that the functionality should work. You don't really need to sit and optimize the visuals and the experience on older browsers because the goal over here is an inclusive internet that does not mean that you have to sit and spend a lot of time in making sure that the aesthetics is good in the older browser. That is not the purpose. So our product should look the same everywhere. This is a common thing that I also hear. And I think that it's okay if your website looks different on different browsers, it will look different on different browsers. You can't help it. Right. You better embrace that and that is and we should better embrace that. That is that is what I think and the riskiest factor in this entire thing is that we write code that runs on client systems. Right. We are not writing codes that runs on our system. This is not that is the thing of especially if you are the front-end developer on the web. We shouldn't ignore the known unknowns. There are so many known unknowns. You don't know what the clients internet speed is. You don't know what the clients screen size might be what browser version that he might be running. And if you start listing them, I'm telling you start feeling helpless immediately. Oh my God. There are so many variables in the system. Right. I can't take this at all. And the thought of not being in control of the situation is really really scary. Right. It's isn't it scary that you cannot control the you do not know how much the capabilities of the system on the client are. You do not know that. So how can you control something that is changing all the time? Isn't web changing all the time? Browsers are getting upgraded. The language is the standards are getting upgraded. It's changing all the time bandwidth is changing all the time. Things are beyond your control. So I said don't control it. Embrace it and progressive enhancement is a way of embracing it because you are making it from a least capable system to scaling it up to excellent system. Now this is an article written by John in the year 2000. It's about 14 years old. Right. Says the control which designers know in the print medium and often desire in the web medium is simply a function of the limitations of a printed page. We should embrace the fact that web doesn't have the same constraints and design for this flexibility. If people have not read this article, I really really really urge you to read the entire article. It is an amazing piece of insight for people who are working on the web further. The founder of Amazon. He told to Jason freed who started 37 signals now base camp. Find the things that won't change in your business and invest heavily in those things and I really really really love this thing because to me this translates to focus on functionality and content out design. Focus on the functionality and content because I guess that will not change people will still like for example if you sell tickets. You can say in the future people will continue to say ask or demand tickets and you should not be thinking about the fact that whether he is demanding tickets from a low bandwidth network or a bad browser or a good browser or all these variables. So invest in the content and the functionality. The other thing is uphold the core principles of web. Right. This is very important. There are technologies that have come and they have gone away because they could not do it. That includes access TML which said that. Okay. If you make a slight mistake, I'm not going to render the pages. It's it's it's not for following the principle that be conservative in what you accept and be liberal in what you give out. It's not following that principle. They embrace all these principles. The other point that Luke says is perhaps ironically the more backwards compatible your website is the more future friendly it is and it is also a food for thought because even the very first website that came out 25 years back is supported on all web browsers today. 25 years of life of a website and it does not break in any web browser today. We open it in your feature phones is where it will work. Isn't that amazing and which basically means if we can be backwards compatible in the dark code. There's a very high chance we'll be forward compatible almost guaranteed. Right. 25 years of website is actually lasted. Don't be fad friendly. Please. Be web friendly. When I was here last time. I gave a small talk on user experience. I ended with this slide. I said that the web is an amazing platform. Okay. I don't know how many of you were here last time. And then in 2003 later half Jeremy gave a talk called the power of simplicity in which he said that it is not right to say web is a platform. Why because what you understand with the platform is it's a zero or one either you have it or you don't have it. It's like the guys I'm on it or I'm not on it. It's like Mac OS either I have it or I don't have it. It's like iOS either I have it or I don't have it. The web is not a platform because he calls it. It's a stack. People might have only HTML support. People might also have CSS support. People might also have JavaScript support. So it's a stack of technologies which is not a binary thing zero or one as a whole. So we should not call it a platform. There's a very subtle difference. He says that you can also call it amazing medium because even in the previous code it's being compared to the print medium the web medium but really I just hope that you all agree and you we are all in the same page. When I say that the state of web is going through a continuous change like devices are getting added technology is getting changed. Everything is happening at a really high speed and therefore I say that web is flux right flux is continuous change and that is what my talk is about. Thank you. If you have any questions you can put it out perhaps. Sorry. Sorry. Before we start question answers those of you who own vehicle numbers 7782 and 5051 you have to move them in the basement. They're blocking other vehicles ASAP gone over everyone like blue over everyone. Okay. There's someone who's raising the hand. It's very hard to see from here. Yeah. So you said not dependent on JavaScript and because there are users and browsers which don't run JavaScript and we got to support those right. Do you have any numbers on how much traffic does come from browsers which don't have JavaScript or users which have JavaScript disabled. I added a point. It is not about. Okay. I'll just go back to that slide properly. Probably. I never said it's because you have to support the system which doesn't have JavaScript. That's not the only reason. Okay. So is it worth the time? Good question. I think you say that it is worth the time because you think that making something that is simpler is something that you leave for the end adding JavaScript is something of a more priority to you. I say that you can build a website with just HTML and you can launch it immediately which is going to save time over you adding JavaScript much more. So if you ask me if it's worth the time or not, I'm not advocating that so I think you're talking about starting from scratch. I'm saying if you have already worked with a place where we have JavaScript with a website and is it worth the time, you know, making it. So here's the here's the point if you've done that already, you're now going to go into a mode of graceful degradation. Right. That's what I am primarily advocating this for future for new projects. Plus if you have one, I also say that you should probably have had done this and if you can take a corrective measure right now, please do it because there is again there have been history instances in the past including the Google Chrome download things not working. So they were using a JavaScript based button which if you click the JavaScript runs and that Google Chrome download starts for two hours, there was a bug and no one could download it. And the problem over here is the language of HTML and CSS are so tolerant that they take wrong code and they still render a page. But JavaScript being a language, it's a programming language. There is no good fallback. You cannot have a fallback for logic. Right. So the error recovery mechanism is really bad. So it's just in just a case of if you build it like that, there is also records on the Internet about if you build it simpler, it's faster. Apparently it gets rendered much faster and specially you also have to cater to another part that you should probably another food for thought is the fact that you are here is an assumption that everyone is using a modern web browser. What you are doing is you are not a catering to the population. There is a huge population who is just getting on board in the Internet. Many of them in villages today are accessing. Do you have any numbers on that? You can pull that out of the Internet. In fact, I can point you to a presentation that talks about this. At the end of this. That is one part of the crowd that you are losing out on. The other part that you are going wrong with is the worldwide web consortium is with a mission that simply says we want web to be inclusive and for everyone. That's the thing. You cannot predict tomorrow there might be a system that does not read JavaScript, but he wants to extract information from your website. You're excluding them. You're excluding a feature phone and in principle, that is very incorrect. Okay. I think phone probably is a different case because most people have a different code base for supporting mobile and supporting desktop. So my okay. So my point simply was don't think browsers don't think devices. Think your content functionality and build something that everyone else. Everyone can use that is what my point was. Okay. Yeah. So earlier we saw a slide where it says HTML is future compatible. So what is your take on deprecated tags? What's my take on deprecated since HTML is future friendly. Firstly, if you're building a site today, you should follow today's standards. Right. In case you're not following today's standards and there is or in case there is an old website like for example, the first website in the world or even websites that are older than the HTML five standards, HTML four standards, they have they are using deprecated tags. The fallback mechanism is if HTML doesn't understand it, it automatically assumes it's a div. So HTML has a very good robust way of handling these errors. So if if you give to a very old browser, a tag called the HTML new HTML five tags like section article and all those things, they assume that it's a div but still render the page. Similarly, if today, if you give a very old tag, like probably marquee probably bling which are deprecated, it will probably assume it might actually still support that functionality. But by default, if it doesn't understand it, it will assume it's a div and still just show the content. So it will not scroll, but it will show. Right. Hello. Yes. So these days websites are turning into web applications. Oh, okay. I just said, but okay, go ahead. Go ahead, please. So that's not about the just reading the content. So these days front end developers use JavaScript for dynamic things. Are you suggesting that we should use server side solutions for that rather than depending on the I'm saying when you build first build it without JavaScript and CSS. Then you add CSS and later add JavaScript. If you do that, you'll automatically support systems that do not support JavaScript or have run into bugs that for which maybe firewall is blocking a .js file. Maybe something has happened. Maybe there's a faulty third party script. If some such things you run into, you always have the server throwing out and spitting out the correct HTML pages. So have that support first and then move on to JavaScript. I'm not saying don't use JavaScript. One question. Now here. So nowadays, if you see the general web application that people are creating, those are single page applications where the next page output heavily depends on the JavaScript UI rendering, the server calls. So in that case, how do you suggest that we should follow this progressive enhancement? Okay. If you just do a couple of projects or even one project, probably in which you say that I'm not going to use JavaScript right now, I'm going to let my server spit out the correct HTML pages because how does JavaScript generate the next page? It has a certain set of inputs. It uses those inputs and decides which is and has some logic built inside that which will decide what should be the next page output, right? The same logic can be actually done in the server as well where you have a post request or a get request depending on what kind of HTTP method you're using. And it takes those inputs, decides what is the next page and gives out output. And you know that is how the websites have been opening for the past 20 years. Isn't that the old approach of JSP and ASP pages where we used to change the page on each request whenever I submit the form, there would be a next page load with the brand new HTML content. But if I see the current approach where we may want to, I mean we are doing some operation and I just want to update a certain section of the page. So in those cases... Here's the thing. I think your server side code should be capable of generating any state. Any state that the JavaScript is generating in the front, the back end code. Again, I'm never saying that don't use JavaScript. Once you make the server side thing, then you have all the JavaScript in the code so that you can also do a single page application kind of functionality, right? I'm not saying that. But in this case, the whole page depends on JavaScript. Why that we are... It depends on JavaScript because you chose to make it depend on JavaScript. It's a framework thing. You chose to pick that framework or you chose to implement it wrong probably because the framework generally never dictates that you cannot have... Because say there's an internal URL. Say you have a URL for the home page and there's an internal URL slash home slash about. Just taking a simple example. And slash about is what you thought was people will come in the home page and if they click on the about link, I'll do some mathematical calculations and do something and I'll spit out the about page. Maybe also, hopefully if you're following standards, also update the URL bar, right? If a person directly moves to about page, then the HTML that is to render on the browser in the first load should be of the about page and not the home page with just a template. That's it. That part is correct. In our company, we generally develop mobile websites mainly for airlines. So this mechanism, what you're talking about landing on the particular page. If someone's land on the search page, we do allow him to land on search page. Someone want to land on home page. We do allow him to land on home page. The problem occurs is the home page creation or the search page creation, everything depends on JavaScript because of framework. That's a framework side limitation. We have to create templates. We have to create scripts and all these things. Let me tell you, I can almost, I don't know which framework you're using and I have not worked with all JavaScript frameworks in this world, but I can almost vouch for it that no JavaScript framework would dictate this upon you that it has to do it this way. You chose to implement it this way. I'm almost sure about this. Probably we can take a look at this thing. Generally, how we should be following. We should be creating the HTML on the server side in the HTML content. If you want to not repeat your code, then you can use Node.js in the back end. It will run the same code to do the templating. Have the same code in the front end. Have the same code in the back end. You can use that now. Now you have that flexibility. If you have a different technology running in the back end and JavaScript running in the front end, still you can have interoperability between the two of them. There are templating languages like Mustache, which work with across plenty of languages. So the idea simply is this. If you do it without JavaScript first, you'll automatically never land into this problem that you're asking. But if you've done it this way, you can probably rethink why is it not working if I don't have JavaScript. What where is the which is the point of failure? And most likely it will be the point of failure will be at the point when the server sends out the page, it is not sending in the complete content in the HTML. It is probably sending a separate set of the templates and a separate set of JSON data is probably something like that. Yes, sir. Same again JavaScript. I can't hear you. Yeah, same again JavaScript. How to do the validation without a JavaScript? How to do validations in JavaScript? Without JavaScript. How to do validations first HTML5 has validations. Yeah, how to show that custom messages Now HTML5 has validations, but you want to know now you're really debating between functionality and style. If you have a required script and that Chrome has its own way of saying that this field is required functionality works. I'm saying don't optimize support at least right. I'm what I said was supported. You might not have to optimize it. You might not have to say that this that this name of this field has a fancy message being generated might not be necessary. And it might not block the functionality. I'm only saying make the functionality available. The second part in this is you can choose to turn off HTML5 validation and do a full page refresh that still supports the functionality if a person does not have JavaScript and it will not exclude a person from using your service from because he doesn't have JavaScript or because the JavaScript has failed or there are even instances when you have a button click which in which you want to override a JavaScript and the JavaScript hasn't loaded it and you click on that and nothing happens because you've clicked in the JavaScript. The events haven't been attached yet, right? You'll avoid all those functional problems if you had not done JavaScript at the very first beginning. That's it. So have I answered your question? So anytime if I want the custom message, suppose the invalid user if I want to show then every time I click on the server. So yeah, it's how it should happen how it will work. Probably it worked ten years back. Submit a form, the form went and the server throw the error saying that these fields are wrong. There is nothing wrong in that, right? It's just a little slow, but if you have JavaScript, you can just make it faster as well. It's enhancement as I said. How the traffic of the network bandwidth? The network bandwidth. For a message. You're saying you are worried about the network bandwidth, whereas the customers you're serving is worrying. So the customer you're serving right now by giving JavaScript will still not be consuming bandwidth, right? The customer who has JavaScript will still be using the implementation that you have right now by doing that, you'll also enable customers who don't have JavaScript and their bandwidth load will be on the network. And I'm not sure if that is a really big issue with you because at this point of time you're not serving those customers at all. You'll actually add more customers. Okay, thank you. Yes, sir. I'll do the other way. I'll support you on some things. We've had issues where we'd had to rework some of our pages just to support Google crawling them. We were rendering them in JavaScript and just for that we had to rework them. So that is, I think in my mind, another big reason why you should start with this HTML, CSS-first approach and go to that. Point for you. Yes, sir. So I actually completely agree with you. I think the problem we are facing is new people coming into the web. They start out with tools like Eoman and the first thing they touch is JavaScript. So I think that to them, the web is that way. Like it's without JavaScript, it's nothing. And I think probably that needs to change. Right. So when you started, in fact, there was an article as well. I don't remember where I read it. It said this. It said, whenever you're starting your project, don't include JQuery, Bootstrap, this and all those files right at the first go. Start with a simple text HTML file and start writing code. And the point at which you see the need to include JQuery. At that point you included maybe this website can be completely done without that. So don't add these the whole bulk of code. For example, if you take Bootstrap today, then you get so much code and probably you don't use 80% of that probably. In that case, you need not probably need Bootstrap at all. You might actually go for something else that just works as well as reduces the page size. Right. Yes, sir. Hello. Do you hate communists? I can't hear you. Do you hate communists? Good question. No. The reason why I'm asking is you never look left. You're always right or centric. Sorry. I'm sorry. Maybe it's because of this light coming from me when I don't know. So the question is, most of the guys here are part of some other organization who are constrained either by money or time. So the philosophy that you just proposed, I'm personally, I'm a fan of it now. But for a philosophy to be implemented, the key is results. So can you give us some real-time examples which have followed this approach and who had the success? First thing, that is my first question. The second question is, most of us, including myself, I think many of them might have this problem. Most of them agree with the philosophy, but no one knows the answer how to achieve it. So can you give us an example on that as well? Okay. The first, your first question is results that this has worked. Right. If you follow this philosophy, the first thing that I'm going to point out is if you follow this philosophy, the product that you have right now, none of its features are compromised. Do you agree with that? Yes. So if your current product is giving you results, this philosophy, per se, will not lose out on those results, except for the fact that it might take you more time to implement it. That is what you're saying. Now, there are two more things over here. One of them is you can make it incremental. You can make it iterative, in which you launch a non-JavaScript website first. It might just take you less time than putting a complete debugged, tested JavaScript website, and you'll be in the market earlier than what you aimed. Point one, right? That might be possible. The second point is, when the incident happened last year, around July, and after that, there are people who did a little bit of research as well. So there's this guy who took Twitter and took, I think, Tweetdeck, if I'm not wrong. Tweetdeck is all fancy. Twitter was, at that point of time, using progressive enhancement. He did a couple of tests on his computer, and he realized that the speeds are faster with Twitter than Tweetdeck, even after the JavaScript was cached. And that is amazing. And I can point you to that, perhaps. Out of this, I don't have all the links in my mind right now. The second part, the question I forgot, the thing was, how do you go about implementing it? Yeah. I mean, can you just give us a simple example? A simple example is, so I tried doing this as a part of the workshop yesterday. There were... So Mr. Murphy actually intervened in between. The networks had some issue, but keeping that aside, what I intended people to do was making a single-page application where I did the complete backend, and they started off with, first, I gave them a list of things that you need to prioritize. The first thing, and after prioritizing, in my opinion, the first thing that you need is reachability of your content, or your functionality, and by reachability, I mean you should have a URL for each piece of resource that you have. The next thing that you need to work on is making the content consumable, that is, making the markup. Next thing is making it functional, that is, the backend thing works, complete backend logic works. The next thing that I came up with was, I think, accessibility, making sure that everyone can use it. Then you probably make sure that the performance is good and make it as fast as possible, that is the next most important thing, and the last thing probably is it is aesthetically pleasing. Having said that, I don't mean that you just chop it off in between, you can do the entire stack and you do it in iterations in a way. You start off with finding out for any application what are the URLs, the routes, that is something you do for your JavaScript-dependent application as well. You write the complete backend, you make the front-end markup that will dictate what content gets given to the user and therefore have a backend ready which will support that markup, which will be able to generate that markup. These are the two parallel things that you do and therefore by the end of these two exercises you should have a website that is no styling, just simply the simple default browser style is being used, but there's a sign-in functionality a person clicks, it's a page reload things like that, the complete functionality works. After that you take CSS and you inside the entire markup without changing on any of the semantic tags, you might add any of the non-semantic tags or classes, you can apply all the styles that you want and as a next step after that you can inject JavaScript in which JavaScript can take control of buttons and things like that. It will be tedious in the first step, in the second time that you do it you'll automatically realize that I know when I am actually hurting progressive enhancement and when I am not and you might be experienced enough at that point of time to take a decision on using HTML doing HTML, CSS, JavaScript parallelly without breaking it for a non-JavaScript case and of course after every single feature or every single module you can just disable JavaScript on your browser and test it once, is it working? Did I break it in between? You will be used to that very soon, but as a starting thing just do the HTML then add CSS and then do JavaScript. Are there any other hands? Okay, thanks a lot guys. I hope you liked the talk.