by Geertjan Wielenga
At: FOSDEM 2020 https://video.fosdem.org/2020/H.1302/beyond_angular_react_vue.webm
An overview of an interesting new development over the past years -- many vendors, large and small, have been making their JavaScript-based technology stacks available on GitHub. What does that mean and how to evaluate this development? Find out in this session, which includes small code demos and tips and tricks. Did you know that over the past few years, large enterprises have been developing and open sourcing their JavaScript technology stacks? On GitHub, you'll find solutions by ING, Uber, PayPal, the Financial Times, Oracle, Microsoft, and many others. Some of these are software vendors, while others are in a variety of other industries. Each of them start from open source frameworks and libraries and all of them are interested in contributions.
The session, with several live coding scenarios, focuses on something that's been going on below the surface, mostly unseen: large enterprises are using open source solutions in the JavaScript ecosystem (e.g., React, Vue, Knockout, Angular), developing their own internal tech stacks, and then pushing these stacks out to GitHub.
Let's explore the advantages of these and see what can be done and how practical these developments are.
Room: H.1302 (Depage) Scheduled start: 2020-02-02 12:30:00
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 John. I work for Oracle as a developer in particular on open source projects. So for a long time I worked on Midpines in Apache. I'm the Apache PMC chair for KNITTING'S. 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 for open source. And I've recently written or put together a book of interviews with developer advocates. So it's about seven hundred eighty pages long interviews with people who are advocates for different technologies and how that ended up being that and what the 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 is 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 Jay Creary and New Tools and Dojo and Jay Creary, these types of frameworks and libraries initially and then maybe a second generation here with Backbone and Imber and out and Anglicize. And more recently, all the discussion is basically about whether to use angular of you 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 in this 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, Grundt, for your for your builds and you're very happy with your knowledge of grunge. And then you say, yes, but you should actually be doing golpe now. So then you spend some time learning gulp and you're very comfortable with golpe. And guess what? Brunch is apparently the new golpe. 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 a vibrant, constantly developing ecosystem, but definitely presents problems if you're creating something more serious, not some hobby project or some small project project, but something more significant. So I would say the three key problems are, first of all, churn. So this constant technology change that you have to constantly keep up with and it's not on the level of that, you have to keep up with JavaScript, but you have to keep up with all these technologies as whole ecosystem around it. And which you then also see developing is the concept of custom stets. So of course, if you use view, you don't just use view. You seven things plus value. And if you use react, you use seven things plus reaction and angular as well. If you want a component library, these kinds of solutions don't provide them out of the box. So you go somewhere else for the component library and you go somewhere else for the built 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 ideal. And what you also find is that people are no longer JavaScript developers, but they view developers or angular developers or reac 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 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 installation. So I come from Oracle, but in IBM and 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 for their business using JavaScript, which makes this problem all the 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 is still going 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 young developers coming 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 SFP 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 doing 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 steps that will attract developers. So, yes, everyone knows basic JavaScript in one way or another. You know how deep that knowledge is. It's a different question. But the Enterprise likes JavaScript. Definitely. So, for example, to give give very simple examples as a starting point, Oracle, SAP, Microsoft, they're 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 launch of into 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 they 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 from 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 with specifications, it's the question of working out as a solution around localization, its thinking about accessibility as well. So this accessibility requirements are 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 this 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 interactive, very graphic, very UI oriented applications typically created a lot in the in the large vendor space as well, looking like this or mobile app. 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 that 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 how transition to the JavaScript world, meaning that there has to be this low threshold entry point into creating these guys. They have to be out-of-the-box solutions. You don't want everyone in your organization or you don't want the organization within your company all figuring out on their own what stack they should be using, but needs to be a standardization, at least across the company. So Comprehensiveness Aaltonen accessibility and standards in particular, and in terms of standards of 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 sites. 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 that's very nice. But in the enterprise 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 this these ones. But there's also PayPal, Woolmark, Financial Times, Uber, Airbnb, because nowadays every organization is an IT organization. So if I show you some examples of this, so you can see my screen. Mudflow like to display. OK, there we go. Great, so what we see here is something called cracking jokes and look at the top, right, that's paper. So People has developed an internal technology stack that they're using and they have open sourced it. It's on GitHub. Who else is on GitHub? Uber. Uber is a is an I.T. organization on GitHub. Their technology stack that they use for their eyes and other parts of their application is online. Airbnb is on GitHub and Wal-Mart is not a shop. It's an I.T. organization. The Financial Times. Not not a newspaper. It's an I.T. organization. All these different organizations are I.T. 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 standardization in this area within organizations is the result of that is on GitHub. And you can take a look at that. So you've seen some of these. Here are some characteristics of this second generation. So I 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 is 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 point is they're not frameworks, but they took it and took it 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 from 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 that and add and remove from it and the following of standards such as the web component specification, such as accessibility guidelines and so on. That the key questions so before you rush off to get out and you find some random acoustic key questions to create questions to ask yourself, first of all, is what does it mean for an organization to put their stack on GitHub? It could mean that 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 GitHub 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 it. And you can see that on GitHub. You can see what four requests are coming in, how the community is operating, who is checking in. I mean, that's the wonderful thing about GitHub. It's all transparent. So that's that's kind of the the the sort of side effect for these organizations that can't pretend that that they are contributing to this because we can all see it if someone gets 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 think big bank, they have the technology stack on GitHub. You should ask yourself, is my business comparable to what I just doing? And 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 steps in the case of Oracle. Here is an example. So here is a this is a completely free open source front and stack. You can see the the server is empty. It can be anything on the backend data coming from anywhere and everything is on the client. So it's a pure, clean solution and it's all free, open source stuff. So Knock-Out is and there is not that cool. No, it's not cool, but it's stable and it's got documentation and there's lots of things on stack overflow, not cowardice. And they're required geniuses in there is required, you know, 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 query, which is now being replaced by Web components, such a pure Web component based solution required for modularity and Knock-Out and optionally type scripts in the typescript of JavaScript Córdova to get it onto the app stores and optionally wetback. So if we take a look. Well, we'll take a look at the end here of the typical enterprise requirements for these large vendors. So stability, proven toolset, that's really critical, responsive design. You don't want everyone in your organization figuring out how to be responsive. Design and accessibility, internationalization, data visualization. You have concerns about security, about performance standards. You want to empower. Business users are not only a code oriented technology stack, but also with the web solution in the browser and documentation and support very important. And in that way, new young developers can be attracted to these kinds of organizations. But traditionally 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 leave you with is maybe stop comparing and reject and instead compare Uber and BMB, Oracle, Microsoft, fight the fight on, get out of the stacks they place closest, match your requirements, make sure that are down there, that they are alive and well and should be being further developed in the business 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 an article, for example, they knock out to acquaintance has adopted four completely valid reasons. But then a developer comes for an interview and says, great, you're doing JavaScript, but I'm a few developer or I'm a reactive or whatever. So I would challenge us to educate our communities that that this is a dangerous approach and that orientating identify yourself that closely with a particular framework. The library 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 test whether your organization will accept your requests and enable you to actually contribute, um, to put it into a picture. Are you focused on the hype around health already using the latest coolest thing, or do you think things that are stable and reliable and that will still be maintainable in a few years time? That's the.