 Hi guys. My name is Ashwin. I work as a developer at ThoughtWorks. So I have a little over 12 years of working as a developer in the IT industry. So I started my career working a lot on back-end software, Java.NET. Over the last few years, I spent some time working on JavaScript, front-end applications, and finally in large enterprises. So during my experience here, there are a few lessons I've learned, and I'd like to share some of these with you all. So the intent is to help you be more productive within an enterprise and also reduce risk for the enterprise, be cost-effective, and enjoy the JavaScript and open-source experience within an enterprise. So I'm going to be focusing on three things. One is enterprise expectations when it comes to front-end software, and next is how enterprises plan their work, and what does it mean when it comes to using JavaScript. And then I'm going to end with enterprise constraints. So let me start with the enterprise expectations. So one of the expectations that many enterprises have is modernization It's a very broad term and not very easily designed. And the need for this is because enterprises, they run similar businesses in different parts of the world, and once a solution is done in one part of the world, there is a very high appetite for reuse within the enterprise. But unfortunately what we've seen is that these kind of reuse is not use case driven. It's often sometimes fictional, sometimes leads to a problem wherein you might end up incurring very high cost if you don't think about this reuse element in modernization. Or if you overthink it without a use case, you end up over-engineering something. You might end up with something like that. So how do we remediate this when we are in an enterprise? So we try to be prepared for modernization. It doesn't mean you completely ignore the fact. You can't do Yagmi, but it's not a very good idea to do all of it in an enterprise. You need to be prepared. So focus on having loosely coupled code within JavaScript. It's easy to couple things within JavaScript, but you can write loosely coupled code. Favor similar server-side principles such as event-driven communication. So whenever you build modules, see if modules can communicate through events. And something interesting happens via an event that people subscribe to that event and then respond. It becomes easy to change things. One example is let's say a login module you have. It can then, once you're successfully logged in, raise an event saying pay this user and drop it. People can respond and show various different pages in different applications rather than coupling it to a certain code. Favor loosely coupled code. Try and share your front-end code as widgets. So more often than never, we try to build modules that post pages. Rather, build modules that give you configurable widgets. These widgets which can be re-skinned and they're responsive in nature. Most important is package your code. Use a packaging you would just say Bower or Node. These are standard tools. They follow a standard structure and they easily share it with you. And provision a private module repository within the enterprise. It's very important. So you can install something like Artifactory. It has good support for Bower, NPM, and JavaScript audience. The provision one of these makes it much easy to share your modules going forward and brings a bit of structure to it. So the next expectation I'm going to talk about is non-functional requirements. Large enterprises come with a lot of non-functional requirements. Primarily they prefer custom analytics because there are security concerns on sharing data. So they try to build their own analytics solutions. And these solutions are obviously using proprietary software and they use different software in different regions in the world. Authentication and authorization is another very big non-functional requirement that's required within enterprise software. And then there is auditing. They want to audit everything. So more often than never we tend to underestimate the amount of non-functional requirements that are there. And we built it in a way that is not reusable across regions. The chunk of work increases every time you try to build the same thing in a different region. So how do we limit it to something like this? Try and build your non-functional requirements in a non-invasive fashion. Instrument your code with these non-functional requirements. Try in favor of AOP as a programming paradigm. Expand the aspect-oriented programming. So you try and decouple these horizontal concerns. There are frameworks that are available in JavaScript that can help you do this. Frameworks such as Angular, AOP, Aspect.js for men. Angular, AOP supports even promises. So you can actually instrument your code and when promises return you can actually win things. And obviously unit test is an important part because it wants to become instrumental. The third one in the boring world is metrics and documentation. So one of the things with enterprises is they do engage a lot of vendors. And there is vendor churn, right? Vendor goes away, vendor comes. And sometimes enterprises want to take on the ownership of the code that is built by vendors by themselves. And there is high expectation for documentation and some amount of knowledge transfer that happens in this situation. And whenever you build software, there is a lot of reporting and KPIs related to repress and quality associated with the software that you build. So if you don't plan for this early, it will result in ineffective knowledge transfer in the enterprise resulting in a risk to the enterprise high cost. If you don't put in tools that can help you measure quality, you end up with quality software and there's a pile up of issues towards the end, which are hard for these people. And then the most boring part, which is a pile up of documentation that hasn't been done and has to be done once you lose a lot of context. I've been in situations where I've had to work on documentation because it's just part of the definition of that. So we are often there to leave it to the end. So choose a JS analysis tool. There are tools which are similar to server side tools that can generate quality tools things like code complexity, duplication. They can generate key maps of areas of code that need attention. So there are tools that do that. Sonar, Plexo, ESMint, the simple one. Putting these tools early as you build your JavaScript front end software helps you build much better quality in the report. And I've seen that there's a need for integrating some of the reports that are generated out of these tools existing back in reporting tools because enterprises prefer having a holistic picture of software. They do not want reports just for a front end and then the back end. So there is always this desire that comes and then you realize that, okay, how do we do this? So plan for this early, know that this is coming. See what tools are already there, reporting already in the enterprise. See if you can integrate with that, your front end reporting as well. And use JS Talk for documenting your code. And if possible, try and build live documentation. In my experience, I've worked on tools where I've built live documentation and it changes as the code changes. So you don't have to worry about doing and updating the documentation when you change code. There are ways to inspect some of the runtimes such as Angular and you can actually generate some of this documentation. It's not creates the live tool, but saves a lot of work because it stays up to date with the report. So the next thing I'll focus on is enterprise planning. Enterprises tend to budget year on year. And they plan for a year's worth of work. And once this is done, promises are made by the business to their customers. There's no going back from there. And obviously everyone knows in functional delivery issues priority. And I got framework-fitting sometime back. And if you see the JS term to result in frequent rewrites, this is something that can be very risky for an enterprise and increase tremendous amount of cost. And to avoid some of that, what happens is you end up lagging behind an upgrade path and that only delays the whole problem. So this doesn't mean don't do JavaScript, it just means that you don't try and be better prepared for this journey. We all know there's a journey out there. So prepare for this journey, protect yourself from journey. And try and create a JavaScript tech product in the enterprise. I'll talk about what this is. So how do I prepare for this journey? So all of us are used to writing server-side software where we layer our software and each layer is designated to do something and you delegate down, right? Rather than coupling with each other. So try and layer your JavaScript. It goes also in a similar way. Our JavaScript applications, front-end applications are quite heavy now. There's a lot of logic in there as well. And you can't afford to layer it in a way where your top layer, which is your controllers, are tend to be bound to a certain kind of framework such as say Angular or Rambler or React. And then your lower layers, which are your facades that orchestrate talking to services about visual storage, try and keep them plain on JavaScript. Because when you experience churn, then it's only the controller layer that takes the bit. And the rest of it is hopefully easier to change. And favorite dependency injection, because this helps you to unit test your code. So you could use something like ECMAS 6 modules. You could use required AS, system AS, or multiple tools out there that help you to dependency injection. It's a good practice. So now that we've prepared, you want to protect yourself from this trend, right? So I might be preaching to the court, but it's important to have very high unit test coverage and very early as well. Of course, try and decouple these unit tests from the framework itself or from the churn, because if you have to change all your tests, when you have to change the code, then the whole purpose is defeated. I also recommend having high functional test coverage for front-end applications, because they don't make too many assumptions about the underlying tech and they're kind of isolated from the fact that you choose Angular or you choose Angular or you want to change one from the other. So that is the ultimate safety net that you will have when you're making these kind of changes. And for enterprises, please factor these upgrades into your plan. It's very important. So I spoke about the JS Tech Red-Up. So the intent is to bring some long form of consistency in this world of churn and JavaScript within an enterprise. So put a whole group together that helps determine what JavaScript frameworks that you want to be adopted across the enterprise. These are things that work well for the enterprise and you want people to use them more, socialize this. There could be projects that can absorb over the risk. So you might want to trial some of the JavaScript frameworks on these projects. There could be some that you're just spiking on and trying to verify does this make sense for the kind of problems that you're trying to solve. And then finally, old is what I recommend not to use world power within the enterprise. So this helps bring consistency in your choice of frameworks. You periodically come together to refine this Red-Up. The ThoughtWorks does have a technology Red-Up there as well which you can refer to. It's curated at regular intervals. But I encourage you to go there and see what the recommendations are. So the last bit is enterprise constraints. Some of us have worked in enterprises where there are just too many constraints. So obviously the browser ecosystem, even that we're working on JavaScript. So what I have seen is enterprises like to have their software working on every version of the available browser. Even the oldest one, IE6, that's not the best one. And I used to mostly wanted it working on IE6. So most of these browsers that they wanted to work on are not available in the enterprise at all. And it becomes a real problem trying to get these browsers in because then testing takes a long time and you delay delivery. And some of the JavaScript choices that you make based on this recommended set of browsers might need polyphony which may not perform. So you run the risk of high maintenance based on browser choices. You also have low performance if you end up polyphony. So how do you mediate this? Drag the browser choices through past another bit. So the analytics that you have from other applications in the enterprise can guide you as to what the browser set your users are currently using. And align your technical choices to the supported set of browsers. Know what browsers are going to be supported and avoid polyfilling wherever possible. And also please set up a process to get these browsers into the enterprise as these things take time. So the next one is a lockdown environment. Very often you get into an enterprise and you do an npm install and you find it doesn't work. So you realize that there is limited internet access. You are used to the fact that you are going to be installing these things from the internet. And everything requires a lengthy software approval process. You go register for an app and it goes to multiple levels of approval and finally it arrives somewhere and you can install it. That doesn't work very well for using something like node or bound. Often this becomes a barrier to using open source within an enterprise and could result in tremendous loss of productivity. So prepare for open source within an enterprise when you are there. Try and provision an internal package repository. This makes them more comfortable given that it is only one repository that accesses the internet. So something like artifact. They have more control because it's just one. Request for read-only github access because when you say github access then you feel that you might write something. And software internet access because it's key to being successful with open source is obviously the forum support that you get with it. If you can access these forums, it's really hard. The last one I want to talk about was and the most important one for enterprise is compliance and security. So the majority of the functionality moving towards the front-end and in JavaScript you find that data gets stored in the browser. It gets stored in the fashion that it gets stored on the disk. And if we don't realize the vulnerability is there could result in a regulatory violation for an enterprise which is something which is quite unacceptable. And there is reputational risk, there is financial risk if the data is going to be vulnerable. So there's not much you can do about this but some things you can just set up a certification in the approval process early. Again a process where you certify whatever data you're going to be storing or sharing in the browser is secure and it's compliant with the policies that you request for. And lastly, we end up minifying our code get an approval for licenses and make sure your minification doesn't get rid of the licenses. So maintain the licenses as per what is required in your minification. So these were some of the things that had to learn sometimes the hard way and for a period of time we feel they're doing much better than this. Just wanted to share with you all. So often what happens is one question for example is when you store data in the cache of the browser rights data does it write it in plain text? Is it stored in plain text on the device? This is something which we don't often pay we store it in the HTTP cache we assume it's encrypted it may not be. And what happens if the computer is just left around someone gets access to it. So when you sign out of a web application how often do we delete those caches? Sometimes we just can't, someone has access to it. So these sort of questions are left unanswered and are discovered rather later. So there are companies that specialize in certifying the fact that their software is doing the right thing. And what kind of data is stored in caches and things it inspects, right? Your application tells you whether there's a browser and then based on priority or you can decide whether it needs to be fixed or not. But there is a risk to an enterprise when it comes to storing data on the device. Yes, I'm just going to make it clear to myself from your selection. So what kind of a JS framework did you use actually? So I have worked with Angular 2.0. Angular 2.0? Yes, I've worked with Angular 2.0. You've been experimenting with React and Ember but primarily I've worked with Angular 2.0. All this really makes sense but the way you think about this right in our deadline limit at the point of time. Exactly, right? So the whole point of this was to share with you all in that moment. Be aware that you're going to run into all of this and start by asking these questions upfront in your end of question. There is a planning phase. If you're doing agile, you will be doing a nutrition zero where you get most of these questions answered. And what happens is if you don't have the answers then you can factor it into your velocity. It's better than hitting this wall or multiple walls at periodic intervals where it's very hard to react. I go back to the point where those promises are made by the business and it's very difficult to go back and repeat it intervals and say, hey, by the way, you can't handle this because I don't have IE6 installed. It's going to take a couple of weeks. Just share, be aware, plan well and advance from these things. So is there any process to decide what kind of a case paper there's a pair of them? Is there any comparison beforehand? In terms of securities, in terms of that? In my experience, what I've seen is that the kind of problems that enterprise can to solve business problems, common business problems, they are solved using maybe an angular or an angular equation. I find it very hard to decide based on the capabilities of the two frameworks on which one is better. They both rank up the same, for example. But then when it comes to things like what experience your current team has, the kind of skill sets that you're able to hire, I think those are some of the decisions in an enterprise that make it more prudent to choose one over the other. So capabilities are barely found easy to say that, okay, we should go with them or we should go with them. So basically it's from the majority of the what these developers have to do? Yes, so what I've seen is that once you ramp up on one of these frameworks, it's hard to finish one other one because the value that the other framework brings isn't too much for the kind of problem that they're going to solve in an enterprise situation. So in that, we just take one framework The decision making to choose the framework is not entirely on the features offered by the framework and multiple other things you need to think about. And skill sets you have, for example, there's vendor churn, what are the skill sets within the vendor? Learning curve is another important thing. We hope that you have questions. Thank you.