 I don't want to introduce about myself because this entire session is about introducing myself. That is what you are going to see because I'm going to run through all that I went through. And whatever that I put across may not be the accurate fact. This is what I observed over the 15, 16 years actually. The story that I'm going to tell you started a little earlier than it is mentioned because I joined around 2003 but the story starts a little earlier. So the idea is I'm here not for making this after long time. I'm actually making a presentation without code actually. So if anything doesn't go wrong, anything goes wrong, please excuse me. So okay, so confusion and confusion of the web developer. So the session itself will speak, so we'll get into it. So the agenda of this is how I entered into the industry and how you become a king of web development. If not a king, how you look like a king? That is what I'm going to talk about. So now when I started my career, I started with an airline company where we make softwares for airline ticket booking and all those stuff. And our people are very, very, very strict about UX and all those stuff. And when I started in 2003, there was no rich client and all those stuff. At that point in time, they draw a flight and then they want to book the tickets inside a flight. And we can't get into that discussion and all those stuff we need to do. We have no other choice. So at that point in time, there were two kind of client. So I'm talking about the time where there was no Chrome. The web is not considered as a client at all. So there is something called thin and thick. What is thick? Usually when I say thick, if anybody familiar with VC++, Swing, DB, all those things, they are called thick clients. How many of you have worked on that? Very good, super. Okay, so how we differentiate between thin client and thick client? Thick client, let me talk about thick clients. Thick client means they run on your client machine. So for example, applications like MS World, PowerPoint, Photoshop, they never intend to run in web. Because they run, first of all, they run on your client. And they run offline. You don't need internet connection to run your applications. And then the application state navigation, that is quite tricky. When I say application state, when you go from one screen to another screen, what is the data that you pass and what is the current screen's data, these are all maintained by the client. And flexible with screen size, okay. So they provide a lot of options where there is something called grid layout, grid back layout, border layout, and all those stuff. The purpose is you take a screen and you minimize or you maximize. Your screen should look solid. And as you keep minimizing, it will keep adjusting. So basically it's flexible layout where the layout does not go and sit there, rather you say, okay, if this much of size sit here. If this much of size, it's like a planning, actually. Planned layout, we were provided with planned layout. So that is one and another thing. Then we usually do thick lines with programming languages. Java, VC++, and all those things. But actually this thin line, right, that is thin client. But whereas in the web, they don't have anything like a programming language. They use something called the JavaScript, which is at that point in time scripting language. It never considers a programming language. And then we used to develop components. We used to develop components. When I say components, a component is not just a text box, combo box, kind of stuff. A component can be a flight, a component can be a room, or a component can be anything that you will be able to visualize. So that is not a component, but you can't even think about components in this. And finally, or most importantly, when you make a connection to the server, it is not just a HTTP. You can make a binary connection also. But the problem, the thing is, they render only what is modified. They don't render your entire page. But whereas here it is all pages. I don't know whether anybody did the paging, at least. So now I will start with the web. What happened to the web at that point in time is, it started around 2000, I mean, I'm just starting from 2003. There's something called servlet. When I say servlet, you write your code. You write code to generate HTML. Think you keep writing your JavaScript literals alone to create the entire application. You will screw up the application, right? And that's what we are doing initially. And then came JSP. JSP is kind of a markup where it looked like HTML. It looked like HTML. And then we put, at that point in time, it's an interview question to clear the interview, one of the standard questions that we will be asked is, what is the difference between servlet and JSP? If you put HTML code inside Java, it is servlet. If you put Java inside HTML, it is called JSP. And that is how we clear our interviews. And then we all were safeguarded by this guy called Strats. I don't know how many of you are aware of Strats. But Strats is the core reason that we got into at least three digits or four digits salary, actually. At that point in time, if you know Strats, Strats does nothing. Model view controller, the separation of concerns. It will do for you, for your web development. At that point in time, it does a breakthrough. And then we got all our salary takes there. But actually, technically speaking, I think around 2006 it all started. There was people called Tapestry, Vicket. These people, they make component framework. When I say component, it is not the component that we use today. Rather, instead of constructing pages till what we were doing, they started constructing individual components. And then each of these sections are component, but still they were rendered in server. And then 2007, somewhere, JSF came. And then entered GWT. GWT, when GWT came, the idea was very, very new. And people started using GWT, not for any specific features or something like that, because of one single tagline, because Google runs on GWT. And everybody started using GWT. And finally, within six months or something like that, Google decided, no, it's not a good idea to use Java to generate HTML. Scrap it. We scrap, but the projects are gone. So now this is what happened. And this story will come to this later. It's kind of a nonlinear way that we'll go. And my interest towards after started like this, actually. When I joined the industry, I was also one of the developers who thinks that it's the programming that gets into the software job. And then if you go to a software company, every individual that you see are programmers. That's a misconception that I had, like anybody else. But when I entered into the industry and then I got into the company and then I was working day and night, like any other pressure, though, I looked into a specific set of people. And their characteristics were very, very unique, actually. And they always come on time and live on time. Nobody questions them. Every time you go to them, they will give you a set of diagrams. They don't speak. Their diagrams speaks, actually. And then whenever we ask a question, the answers are set up predefined. And the best practices are also kind of predefined. When I don't get both, they will give book references. They will say, OK, go and refer to this particular book. And then finally, as they grow, independent of whatever they do, their growth is actually guaranteed. And these are some of the questions. What is the database? And then they say, Oracle, there is no choice for stuff at that point in time. So they say, Oracle, very good choice. And then how do we connect? There are three connections. It's quite tricky to make this decision, actually. There will be three options. JDBC, EJB, Hibernate. Relate that with your JavaScript framework. Relate that with your JavaScript. There are three options. That itself was difficult at that point in time. Now, system integration, JMS. Containers. Containers. At that point in time, the containers are like WebLogic, WebSphere, all these things are there. And when it goes to container, it is like a next level for those people. So they will ask containers, that's tricky part. What is the license that you have? Do you have IBM license? OK, use WebSphere. Do you have Oracle license? Use WebLogic. And that's how they decide containers. And these people are called solution architects. And at that point in time, I decided I will also become a solution architect. And this is how the back-end solution architect's life cycle is. Somewhere there, we started with J2EE. And then we need to upgrade ourselves. After two years, there came Strats and J2EE. After that, Spring, MVC, and Hibernate was a trend. After that, Spring and JPA is a trend. You might ask, what is the difference between these two? All are same. Only name is different. And then Spring, MVC. After 2002, it became easier, because Spring itself integrated everything. So you don't need to go out of everything that you ask. It is like, after a point in time, it is like Spring x, Spring y, Spring z, Spring a, b, c, like that, actually. And then came the biggest market disruption at that point in time. And architects who knows that technology are considered cutting edge architect, actually. And I was one of that, actually. I was having a lot of promotions and all that stuff that point in time. And what is that major disruption that happened at that point in time in that one is Spring Boot. Whenever I started using Spring Boot from the day one. But the moment we talked about Spring Boot, people are really, really, really happy that we are using the latest technology and all that stuff. What is Spring Boot? It is still Spring, but it boots itself. Nothing else. But then that is how the architect's life is. But now I'm coming to our actual story. Please give me the honest answer. How do we choose a JS framework for our application? I will give you the honest answer. So the way that we choose, we need to consider memory utilization, performance metrics. You create a scorecard, ease of use, portability, and all those stuff. And that is how we choose JavaScript framework, really? No, no, no. So now, first of all, let us come to the confusion part. Then we will go to the confessions part. First, the confusion part is this. You need to choose a framework. And I'm just looking at the frameworks. What they say. EmberJS says a framework, it has taken from their own site, actually. A framework for ambitious web development. An Angular is for superheroic, progressive, and React is very simple, JavaScript library for creating building user interfaces. Now I ask my customer, is your application ambitious? Yes, of course it is supposed to be ambitious. Is it supposed to be superheroic? Yes, otherwise I can't beat my competition. Then progress, yes, yes, we need to progress. And then building user interface, what nonsense, new year building and user interface. Now choose the best. And everything looks similar. And then how do you choose the best? So now, the biggest tool, even though the problem is very, very difficult, the solutions are very, very simple. I'm going to list out four logical, mathematical, proven solutions here. So I followed it at least, let me honestly admit it. I followed it. So the first and foremost, the biggest friend for an architect from the front end is Google Trend. Any time you want to analyze the technology, go to Google Trend. And then check. So now look at React, Angular, Mujes. 75 is greater than 50, and 50 is greater than 20, which means React is greater than Angular, I use React. And that's how I choose React. And now the second thing is because someone else uses it, because Google uses it, because Facebook uses it, because Netflix uses it. And that is actually relatively easy. But just consider a civil engineer, and then you go and you want to remove. You are constructing a house. You want to move something from here to here. And then he's saying, OK, use the biggest crane that you have for this multi-story, because Ellen uses it. It sounds stupid, but that's how I actually make things. And the next thing is, in fact, the next thing that's, I once had this problem. In the initial days, when I didn't know this, Farmers and all those stuff, we had a huge debate with my director, React or Angular, which one that we'll choose for our application. And then he told Sadish, as a senior engineer, you need to go and choose. And I was looking at React, good pros and cons, Angular, pros and cons. I was not able to make any decision. And I told him that, no, I can't make any decision. And then finally he told Sadish, you are experienced. You should know how to choose the framework. I will tell you, you choose React. And then I was kind of like, I was really, two things. One is, first of all, he told the answer immediately. Second thing is, how come? Because I evaluated day and night. I couldn't find any difference. Anything that I can do with React, I can do with Angular also. But what was the difference? Then he told, OK, you know what? Why I selected React? Because there is 10 people sitting in the bench. They know React. And that is what we do. I know this. I know only this. And then the selection becomes simple. You don't even have the choice. And then new technology. We need to, I mean, it's not a problem with the development in message. But as I have been in the service industry for quite some time, whenever I go to a client, a client wants new technology. They don't care. They want new technology. Once I had a heated argument with my director and then said, no, this anyway will be like, we know that if you choose this, application is going to die. And then he said, OK, no problem. What is your problem? I said, OK, no, the client will not be happy. It's not ethical. But then he told, if you don't do it, he's going to shift to somebody else. And then he's going to do that. Anyway, instead of somebody else do it for your client, you do it for yourself. You choose a new technology. Anyway, if the problem comes, he's going to come to you. Again, it is your work. Then that was a logical answer for me, because anyway, it is going to come to me again. So that's how we chose new technology. So these are all the main factors that we choose this. So now why it happens? So when these kind of confusion happens, I want to understand why it actually happens. What is unique about this web development? What I understood is what I'm going to present. In fact, this is the main thing. So unlike other languages or other libraries where your Java is developed by Java developer, dotnet is developed by dotnet developer. PHP is developed by PHP developer. But web, Java developers comes into web. PHP developer comes into web. Dotnet developer comes into web. And they come with their own pros, their own cons. And that is why this field is not standardized. And then, again, we will resume the story. I actually stopped there, the reason being, until then it was like a flat story. There was nothing interesting. There was no fight. There was no emotion, sentiment, nothing. So now the actual story starts. So around somewhere in 2000, the first thing that happened is, wherever you see this mark, those are the places where there was a battle. People were fighting with each other. And what happened is, it's about choices. Whoever makes a choice, if the choice means the company wins, that happened. And then in these three, there are many of them, but I just put significant events only. So when first time JavaScript became like a library and then people started using real good UI components, and then there was a fight between jQuery, dojo, OUI, and DXTGS. And most of the enterprises chose OUI. The reason being, anybody can guess. Because Yahoo uses it. You learn the technology immediately. So now who? But the problem is ultimately, who was the winner? jQuery. jQuery was a winner so much so that in W3C, more than you find a JavaScript answer, if you find a question, the answer will be in jQuery. And then people who chose jQuery, they were all winner. And then Ajax came into picture. Ajax is, by far, I would consider the most significant thing. See, whenever we read about technology, it's also good to read newspapers also. There are news that makes decisions also sometimes. So this is the time that applications like Gmail and all those stuff can. In fact, Google proposed Ajax. So what happened is, instead of you render an entire page, you render only a specific component. It might be a cakewalk for anybody who is doing it now. It is just a fetch call now. But then, trust me, at that point in time, you were asking a lot of people, how do you do Ajax? If you know Ajax, you will be promoted. That much of hype they were giving for Ajax. It is three lines of code. But you are struggling to understand what is the three lines you could be doing. How is the page not reloaded? How is page not reloaded? That is how you are learning that technology. And from there, it actually goes upwards. And then this is the actual journey. Now, what happened is, people wanted to, see, at least at that point, when Google did that, everybody realized what is the market value of an internet. And everybody wanted to control it, actually, to put it this way. And there were technologies that were made. Till then, where is your publication then, it runs on browsers. And then what happened is, this is quite significant. I don't know how many of you used Flex. Very good. Then you should know what is the side effect. Companies lost plenty of money just because of Flex. And I earned plenty of money just because of Flex. Because at that point, not many people know Flex, actually. So now what happened is, now, yes, there is a limitation with this web technology, HTML, CSS, and JavaScript. And nobody wanted to upgrade those technologies also because there are a lot of politics and all those stuff. And then at that point in time, what some good people decided is, OK, we will give it to us, we will manage it. And then this is from Adobe. This is from Microsoft. This is from Google, I think so. So what they did is, they developed your application still runs on browser. And they run inside a Flash player. Your application still runs on browser, but it runs on Microsoft Engine. Your application still a browser, but it runs on somebody else. Which means it is technically not a browser. They are going into some preparatory technology. And at that point in time, everybody realized, OK, if we leave it, we all are going to be losing it. So they all came together. And at that point in time only, JavaScript started, evolving, HTML started evolving. And then people decided, OK, rather we fight within ourselves, let us develop HTML. Let us develop CSS. Let us develop JavaScript. And that is the place where it actually started. Now, the first thing, the colors I matched it. Sorry, last minute I prepared the presentation, but you can match it the color. So we will solve the problem one by one. What these claims were enjoying, we also want to enjoy. That is how it all started. In fact, there's a side story. What happened to the desktop claim? We were doing it with VC++ earlier. And then it became to AWT. And then between VC++ and AWT, AWT is platform independent. In swing, it is like plan form, independent components. Then Eclipse wanted to take it out of Sun Microsystem at that point in time. Then it becomes Eclipse RCP. And then Java FX. Till date, Java FX, everybody technically knows one of the best framework. That's OK. But who knows Java FX? No, nobody. The problem is the desktop client itself is gone. When the desktop client itself is not there, what are you going to do with that good framework or excellent framework? And that is what happened. The story is gone. Now we are into the story now. Now, Media Query. What Media Query did in this one? So responsive layouts, flexible layout. Yes, flexible screen size. Thanks, thanks. So flexible screen size problem is solved with Media Query. And then came Node.js. People talk a lot about server side of Node.js. But server side of Node.js, I think there is still the risk. It is still not true. But the biggest part that I think, the value added at Node.js brought in, which nobody can deny and nobody can actually remove, at least in your future, is the client side tooling, where SAS and all those people are only applicable to Ruby kind of a platform. But now SAS is applicable to us. All the web development tools are now coming in Node.js. Now SAS, why is Node.js and SAS are in this particular color? They are programming languages. OK, Grant. So Grant is the guy who first brought a proper build systems into JavaScript world. In fact, this is one frustration that I had, actually. And I evaluated Grant. I was one of the person who captured that new technology earlier, and I introduced him in the team. And I delivered the product. You know, when I delivered the product, I should be appreciated. But then people were saying, OK, what is the technology that I use, Grant? Why do you use a legacy software? How come Grant becomes legacy? Because at that point in time, there was something called Gulp. There was something called Gulp. And the technology gets outdated just like that, actually. And then Backbone.js. And Backbone.js is the starting point for many MVC frameworks that you see now. And slowly, they are covering all the areas, like applications, state, navigations, maintained by this thing. And then Core.dev and Electron, what do they solve? They run in your client. They run in your client machine. And then finally, local storage, your offline storage, and web component. That is the place where it starts. So finally, this is what I understood. So the lessons that I learned is not just technical. We are supposed to be tactical, also, if you really want to work and survive in web development, actually. A vast experience that you have, consider it is a waste experience. And play like a king. Whenever I say play like a king, whenever we talk about a client, a client will be going and fighting. No. If you watch movies like Braveheart, Gladiator, and big fan of it, this king will not be there in even a single frame of the battleground. When will he come? Once the war is over, he will come, and then he'll think about strategy. And this is how you need to play. And don't trouble the trouble, because if you trouble the trouble, trouble troubles you. And then web is a platform. It is a topic of its own. Because still, many people consider that what is web? HTML, CSS, JavaScript. Then what about REST? What about JSON schema? What about JSON LD? Web is bigger than this UI, actually. And then concepts, tools, techniques, and frameworks. If at all, one thing that you can take from this session, if at all, anything. A simple formula is always in this, if there is a new concept comes, they stay for a longer time. Tools, no problem, because it's use and throw. You can easily migrate. Techniques, be a little bit wary about, before you adhere to a technique. Framework, be careful. But whenever someone says, OK, we're coming with a new technology in web, please stay away from them. That is what I learned. So now the story ends. So everything we got, everything covered, we are going to rule the UI as a web development. That is what the story ends. But then it doesn't stop there. What about these things? API first, IOTN finally, there is someone called Golden Krishna who is saying no interface is a good interface. When UI itself is not there, what am I going to do with all these new technologies? And I don't know whether it will happen or not. But if it happens, it's up to us. Thank you. Thanks for that. Yeah. I'm going to have to rebut about, say, no interface. And yeah, there is a whole voice down to the edge of UI for the user experience. So it may not be something that we see described just simply the UI itself. Yeah, it's not like no interface means removing it. But the more amount of interfaces that you create, it will be reduced. That's the idea. I'm just considering two things. Earlier, you used to use Net Banking directly. You used to use Net Banking applications. But now you consider from WhatsApp, you can send it to Twitter, you can send it. Which means your AP is your interface. It's not your UI. So slowly, that will get reduced. It's my understanding.