 Very much for coming to this talk. I want to talk about a topic that I've heard very little about The second generation of JavaScript technologies and libraries that have arisen over the past years And I want to maybe first of all talk about what I would mean by the first generation And then introduce you to the second generation and hopefully you'll learn about some new technologies out there So who I am? My name is here John I work for Oracle as a developer in particular on open source projects So for a long time I've worked on net beans in Apache. I'm the Apache PMC chair for net beans It's an Apache project now Also work on something else called Oracle Jet, which is a front-end toolkit for doing user interface development Free open source and I've recently written or put together a book of interviews with developer advocates So it's about 780 pages long interviews with people who are advocates for different technologies And how they ended up being that and what their day looks like and the ethical dilemmas of being a developer advocate If you would like to review this book, let me know and I can get you a free copy for your blog or whatever It's out there so to very quickly get to the point JavaScript's been around for a while and One could talk about a first generation of Frameworks and libraries having having been developed at some stage. So first of all initially we had Solutions like jQuery and Mood Tools and and dojo and you know jQuery these types of frameworks and libraries initially and then maybe a second sub generation here With backbone and ember and knockout and angle of JS and more recently all the discussion is basically about Whether to use Angular or view or react. That's basically in terms of front-end. That's the discussion that you hear all the time now Of course, we know that This massive proliferation of JavaScript libraries and technologies is wonderful on the one side because it shows that There's innovation and there's new ideas and so on but on the other side That means it's quite quite a big problem to make the right choices Now what is the right choice to make and so you spend some time learning grunt For your for your builds and you're very happy with your knowledge of grunt and then your colleague tells you yes But you should actually be doing gulp now So then you spend some time learning gulp and you're very comfortable with gulp and guess what brunch is apparently the new gulp And in the meantime there's something else again and this constant churn is really very specific and very typical to the JavaScript ecosystem which simply shows that it's it's a vibrant constantly developing ecosystem, but Definitely presents problems if you're creating something more serious Not some hobby project and some small project project, but something more significant So that I would say the three key problems are first of all churn So this this constant technology change that you have to keep a constantly keep up with and it's not on the level of that You have to keep up with JavaScript, but it's that you have to keep up with all these technologies as whole ecosystem around it And what you then also see developing is the concept of custom stats So of course if you use view you don't just use view you use seven things plus view And if you use react you use seven things plus react and angular as well You know if you want a component library these kinds of solutions don't provide them out of the box So you guys somewhere else for the component library and you got somewhere else for the build system And as soon as you have a problem and you go online to stack overflow for a solution It turns out it's a great solution However, you're not using the two or three things that are specific to the solution on stack overflow You're using a whole different stack. So everyone has their own custom stacks, which of course is not a deal And what you also find is that people are no longer JavaScript developers, but the view developers or angular developers or react developers I mean, that's crazy in a few years time those Technologies won't be there and you can't be that tightly coupled to these solutions So, you know these statements here for the first time in history we have people identifying by framework instead of language and People identifying themselves with a framework is a tragedy This is what I would like to post to you and This becomes even more complicated Because over the past years large enterprises have started using JavaScript as a front-end solution So I come from Oracle, but in IBM in Microsoft Google, you know, you can you can really see how serious JavaScript is by the fact that the large vendors are adopting it Not as an experimental thing or prototyping, but real creating real serious applications and for their business using JavaScript Which makes this problem or no more complicated? Because in the enterprise space, it's not about what is cool and what is new It's about what is stable and reliable and what what is still meant to be maintainable in a few years time So then you aren't running after the latest hype, but you're running after or trying to find something stable and and reliable So why are the enterprises now looking or have been looking over the past years at JavaScript? In particular because the browser is everywhere. I mean if there was a competition between platforms The browser platform is one it's on all devices and JavaScript is built natively into it So it makes sense to natively use JavaScript rather than proprietary abstractions that the larger vendors have developed internally but to use JavaScript directly and also mobile development and You know young developers coming straight from colleges and so on no JavaScript And so their skills have a far closer match with the JavaScript world than some proprietary technology So Oracle has a bunch of abstractions on top of JavaScript and an SAP does and all of these different organizations do but it takes some time to learn those things and Plus when a developer now comes for an interview at an organization The organization isn't interviewing them But the the developer is interviewing the company because there is so much work as a developer you can go anywhere So are you going to go somewhere where there is a free open source technology stack where your skills that you pick up can Be transferred to somewhere else or are you going to invest time learning something very proprietary to what that particular vendor is doing? So for that reason these organizations simply to be able to attract new developer staff are forced To move into the open source world to create these kinds of solutions these kinds of stacks that will attract developers So yes, everyone knows basic JavaScript in one way or another You know how deep that knowledge is is a different question, but the enterprise likes JavaScript definitely so for example You know to give to give very simple examples as a starting point Oracle SAP Microsoft are all doing things on the front end with JavaScript in some cases node on the back end But could be Java could be whatever but the front end definitely is Very big in JavaScript in the large vendor space. So what kinds of applications are they creating? So in the case of mobile, I mean these are logistics health care type applications But I have very specific requirements that are not common outside the the large vendor space So for example the ability to translate strings. So that's a Russian app on the end there So some localization solution you don't want every single department in your large vendor Figuring out localization themselves and also these large vendors have to follow specifications. So the question is You know keeping up its specifications. It's the question of working out as a solution around localization It's thinking about accessibility as well. So there's this accessibility requirements and just large vendors have to meet and so all of these kind of Enterprise level requirements have to be met somehow and aren't met out of the box by these first generation Libraries and frameworks. They don't provide these kinds of higher-level features these kinds of enterprise features Including graphs and charts and other components. So it's a real problem these kinds of very You know interactive very graphic very UI oriented applications typically created a lot in the in the in the large vendor space as well looking like this Or mobile apps. So these are all kind of in the logistics health care Finance worlds is where these are used now here are some of the typical requirements So one thing is you find that the people working on these on these applications at the large vendors are coming from other technologies From Java or from dot-net or from somewhere else and suddenly they're using JavaScript for the first time So this is whole transition to the JavaScript world meaning that there has to be this low threshold Entry point into creating these UIs They have to be out of the box solutions You don't want everyone in your organization or you don't want organizations within your company all figuring out on their own What stack that should be using but needs to be a standardization at least across the company So comprehensiveness out and then accessibility and standards in particular and in terms of standards of w3c web components standard for Reusability the other thing you find which is so Wonderful and and fun on the one hand, but problematic on the other is you find a wonderful new library online you start using it and You can do the hello world scenario that's in the documentation on the site You want to get one step further and you can't and then you contact the amazing person who created the library and they say Yes, I was doing that last week. I'm doing something else now. Hey, it's open source Why don't you contribute documentation, you know, and and that's over a nice but in the interface space It's very problematic because you want stability and reliability and so on So aside from these organizations, there's a whole bunch of other ones that might surprise you So there's these ones, but there's also PayPal Walmart financial times uber air BNB Because nowadays every organization is an IT organization So if I show you some examples of this, so Kraken, ah, you can't see my screen mid-flow Great so what we see here is something called Kraken JS and Look at the top right. That's PayPal So PayPal has developed an internal technology stack that they're using and they've open-sourced it. It's on GitHub Who else is on GitHub? uber uber is a is an IT organization Ubers on GitHub their technology stack that they use for their UIs and other parts of their application is online Airbnb is on GitHub and Walmart is not a shop. It's an IT organization The financial times not a new not a newspaper. It's an IT organization All these different organizations are IT organizations and many of them have online presences Where they make available their technology stack for one reason or another so this is the key tip I want to Bring across is that a lot of the research in this area a lot of the standardization in this area within organizations There is the result of that is on GitHub and you can take a look at that So you've seen some of these Now here are some characteristics of the second generation So I'll call this the second generation a gathering of the different parts that are available from the first generation And making a comprehensive solution out of it. So first of all not cool These are not the latest cutting edge libraries and frameworks and so on but they're stable Which is much more important in this kind of environment and the other points is they're not frameworks, but they're toolkits and Toolkits kind of implies flexibility and modularity as something that can be extended because we know the JavaScript ecosystem is changing all the Time and new solutions are coming out all the time. So the most important thing To think about is the architecture of an application since the stack is going to change To make it as loosely structured as possible so that you can extend it and add and remove from it and the following of standards Such as a web component specification such as accessibility guidelines and so on But the key questions so before you rush off to GitHub and you find Some random cool stack key questions to key questions to ask yourself. First of all is What does it mean for an organization to put their stack on get up? it could mean that's we don't care about it anymore and We're going to pretend that we care about the community So we're going to put it on get up and say hey, it's there and please start using it It could be so it could be a sign that the company behind it doesn't care that much about the technology stack So you need to really evaluate You can and you can see them in get up You can see what poor requests are coming in how the community is operating who is checking in. I mean, that's a wonderful thing But get up. It's all transparent. So that's that's kind of the these the sort of side effect for these organizations They can't pretend that that they're contributing to this Because you can all see it. It's all on get up. That's really wonderful about it And secondly before you pick one of these stacks think about whether the business that that's that stack was created for is Comparable to the business that you're doing. So for example, I and G big bank They have their technology stack on get up you should ask yourself is my business comparable to what I and G is doing Am I also in the financial world or if I'm using uber solution is what I'm doing comparable to uber So try and map your requirements to what these organizations are doing and based on that evaluate the stacks So in the case of Oracle here is an example So here is a this is completely free open source front and stack you can see the server is empty it can be anything on the back end dated coming from anywhere and Everything is on the client. So it's a pure client solution And it's all free open source stuff. So Knockout is in there. It's not how to cool. No, it's not cool But it's stable and it's got documentation and it's lots of things on stack overflow Knockout is in there require J. S is in there. It's required J. It's cool. No, but it's stable So these kinds of considerations make sense in This kind of environment So in our case these kinds these are the typical libraries These are the standard libraries that every Oracle front-end application now has so it makes use of of jQuery which is now Being replaced by web components. That's a pure web component based solution required J s for modularity And knockout and optionally type script either type script or JavaScript Cordova to get it onto the app stores and optionally web back So if we take a look We take a look at the end Here are the typical enterprise requirements for these large vendors. So stability proven tool set That's really critical responsive design. You don't want everyone in the organization figuring out how to do responsive design and Accessibility internationalization data visualization you have concerns about security about performance standards You want to empower business users? So not only a code oriented technology stack But also a WYSIWYG solution in the browser and documentation and support very important and in that way new young developers can be They would stay far away from them especially now where you can go anywhere and everyone is working with With these solutions open source So the key challenge that I would want to give you with is maybe stop comparing angular redact and view instead compare uber here BNB Oracle Microsoft find the Find on GitHub the stacks that place places match your requirements Make sure that they are that they are there that they're alive and well and that should be Being further developed in the digital community around it and so on And based on that make those choices The second point is we need to I think educate our community about the pitfalls of being so closely focused on the first generation Because these organizations even though like these large vendors even though they have taken the second generation approach They're having a hard time attracting new developers anyway But in case of Oracle for example, they knock out and required your assets adopted for completely valid reasons But then the developer comes for an interview and says great. You're doing JavaScript, but I'm a view developer Or I'm a react developer or whatever. So I would Challenge us to educate our communities that that this is a dangerous approach And that orientating and identifying yourself deftly with a particular framework the library is is not Sustainable so investigate second generation technologies and actively contribute to them as well Find that stack that is closest to your requirements And actively contribute to it to actually text whether your organization will accept your poor requests and enable you to actually contribute And to put it into a picture Are you focused on hype or on health? Already using the latest coolest thing or are you using things that are stable and reliable and that will still be Maintainable in a few years time