 I wrote an article about this recently, and Justin was pleading for someone to talk to this talk of tennis. So I thought, I've already done most of the homework, I might as well just turn into a few slides instead. This is, I work for this company, CXA Group. I started there in September last year. In November we got to a certain point where we decided to scrap our previous major project that was basically the company's one thing that we'd done and start afresh and that's pretty scary. To make it even more scary, we decided to go for a framework that none of us had any experience in and we had to make a decision in about a week and a half because we had to start work on the project, we had a hard deadline. Nothing could possibly go wrong. So easy. So since it was so easy we took our time to actually have a look and start comparing different JavaScript frameworks and try to get some rationale behind our decision process because what can often happen is, I haven't heard of this before or let's just go with that and then you find out halfway through the project that it doesn't actually do what you want it to or the major developer has decided that they don't like it anymore and you're left with nothing. So we worked with frameworks that we had recommended to us at some point because we started asking around so React was recommended. I mean everyone's heard of React but you know just because you've heard of it doesn't mean that it's good or right for you. The other one was view that we had recommended to us as well and these were personal recommendations, people that we knew that had been using them that said yeah this one's worth a shot. Further to that we worked with frameworks that we'd heard of and had some idea of so we'd been following the development cycle and had some concept that they existed in the first place. It wasn't just jump onto Google and you know send me front-end frameworks good luck. So that gave us Angular 2 and Aurelia as you can tell with the Aurelia logo. We set criteria down the things that we absolutely had to have as part of any given framework. The first one we looked at was flexibility and flexibility for us was a framework that would let us chop and change things should we need to. So we're looking on the enterprise level. CXA looks at 12 different countries that we deploy to some of those are low bandwidth and low tech so we need something that's lightweight and it's going to work there but the flexibility would mean that if our state management grew stale we'd be able to drop something else in without too much pain and of the list that we had we ended up with this. Aurelia and Vue were our favorites out of this because they're really easy to set up you could get going without having to think too much. They're fairly new frameworks that I've really learned from Angular and React. They have that flexibility Vue and React in particular they don't really do that much on their own and this is one of the things that's like coming to React having not really played with it much before I expected like I can just install React and away I go except you can't you have to get all the bits together and the developers Vue and I really know this and they give you some head starts. There are some nice starter like what do they call boiler plates for React and there are fairly standard ones that you can choose as well to get you going but they as always they make decisions for you so you need to be careful about what you're doing. So for this we gave wins to Aurelia and Vue because they asked questions they made decisions but it was easy enough to alter it if we went along. Partial credit to React because yeah there are nice boiler plates out there but again you know you can chop and change as you go it's not a big deal you're not signing your life away. Complete fail to Angular too because it's quite monolithic. You buy into the ecosystem and everything works within that ecosystem and this is great if that's what you want to go for. It was just not for us and this is it's really hard to quantify exactly why we wanted to go down this this road because if you're buying into Angular too you've got support there so if that's all right with you that's good but if there's a feature that's not within that particular like that that function doesn't do exactly what you want it to do you're stuck with it and personally I don't like that and within the group of developers that we had we didn't like that so this is why we've ended up with a result for this. Don't feel bad if you're using Angular. Offline support was really critical for us. Not many people really seem to know about the offline APIs these days. On a really basic level you can detect that someone's lost a connection and that's quite critical for us because we're only deploying countries like the Philippines and Indonesia where a mobile connection is not given so you can be sitting there doing something your mobile connection drops or internet or whatever you've got and suddenly your app fails that's not great. Being able to work offline and keep going even though that's happening is really important especially given those countries. If you're only going to Singapore or maybe it's not a big deal there is an offline first movement about actually making your applications work primarily without internet connection and there are big advantages to doing this. For our purposes it's mostly due to the fact that we're looking at like limited connectivity countries I guess for lack of a better term so it's really important for us to maintain a good experience for our users and not have everything die especially when you're in a single page application framework so very sensitive. If you've got Angular 1 installed I can break it for you in seconds and I've made many developers cry by putting a hash somewhere in the URL everything falls to bits so they are still sensitive they're not as bad as that anymore most of them but you've got to be careful. Conclusion was good every single framework has some way of supporting service workers and web workers. React and view have frame have plugins for it so you don't need to think about it Angular has the next one I think it's coming in pretty soon, Angular 2 really has got theirs they're writing so as far as we're concerned it wasn't something we needed immediately every framework covered it for us we're good. I kind of touched on performance especially as we're going into places I mean even here in Singapore if I need to download to look at Singtel anyone work with Singtel then there's something wrong with your site it doesn't matter what you're doing the more that you start with before you start getting into I mean we know the things that have that like images take up a lot of space potentially your CSS I hope is not that big but it happens the biggest problem these days seems to be JavaScript where Singtel but you know you get six meg of JavaScripts to do what I mean if one of us tried to even collectively if we tried to churn out six meg of JavaScripts here we'd have a long like long long wait before we could write that much code and what are you doing with it oh they didn't that's the thing they've grabbed others that the key yeah that's that's the whole point the key is to start Lolo because you'll add plugins you'll keep adding new things it's so easy to say hey we need a date picker google you know date picker for my library done I don't need to write new code anymore the thing could be a meg for all you know but who cares it's faster my machine even when you pay attention and you are a good developer and you care about what you choose with your plugins you still need to start low I'm going to look at my numbers yeah to find out here's our results anyway view in particular it's almost like it wins above the other wins because it's down to about 23k for the base libraries you can get a functional view application in 23k that's less than jQuery that is magnificent reactors are probably about double that really at least these are based on it's really hard to get a basic measure of what these things are so I did my best at the time I really was into about 60k they're within a shout of each other none of these things are going to break your device Angular 2 was about 600k just to render a holy world basically that that's not good in practical usage you're not going to launch a 23k view jfapp there will be a lot more to it there will be a few hundred k at least but you can't reduce Angular 2 down to that there's nothing you can do to it because that's your base level it's only going to get worse as projects get older and as they get maintained it never gets any better because you never get the the goal of suddenly improving the performance they just want a new feature instead so you need to choose that that's why it's so critical for us to make sure that was the case at the start so if you is better than the others in this but the others were good enough that didn't really matter and unfortunately Angular 2 just didn't make the cut next server rendering now the early round of single page applications if you don't have javascript happening then nothing happens and you might be saying well is that any different but the difference is in making sure that something's actually rendered as soon as possible with server rendering you can get the server to render the first hit of the page or even every single page and render for example a static site out of sba at architecture and there are good reasons that you might want to do that for our interest what we're looking at is the first load we have a closed application so that means login screen to get the get that rendered on someone's phone as fast as possible I say phone because most of our users out there are going to be primarily mobile only you want that server rendered you don't want to have to load all the javascript libraries just to see your login screen so it's absolutely critical for us that this is there otherwise our performance is going to be subpar now react and view there are plugins and there's a recurrent theme you'll see here this is why we like the flexibility early on you can just find a plugin for it it'll take care of it for you it really is in progress angular 2 has a really nice way of doing this but it's in progress so they'll get there eventually but you know at least they're going there so that was pretty good maturity was the key one the company I work for as a startup we've just passed our 100 million us valuation here I am telling you about how our main product that every single client of ours users came into existence if we stuff this up then the company goes it's not just a small thing that's on the line maturity for us is making sure that whatever we chose it would be around for the next three years or so because generally speaking if you've got an application that lasts three years without a major tech change you're doing okay it's a major investment we've got a lot of developers working full-time on this there's a lot of money invested we don't want to make mistakes the winner is interesting out of this in different ways the first thing we looked at was how long libraries been around and react that's easy the first 1.0 ish release when the facebook developers said you can actually deploy this to production now it was in 2013 the other three were late last year and you'll say like I've heard about a really for ages now if you I've heard about for a long time angular 2 has been in development forever hasn't it it hit live september last year we started work on this in november there was no way we were going to drop something you've been in production like you know ready to go live in for two months on our company it's not all of that you still need to think about the development cycles and that's something that did turn us away from angular 2 as well if you've worked on angular 1 and watched what was happening with angular 2 it was not great in essence angular 1 to 2 is a complete rewrite you can't just change the library version and go with it you have to really think about what's going on and that was terrible angular is now to angular 4 because they said it took us so long to get to 2 that let's just go versions everywhere everyone can have a version as I'm speaking it's probably up to five or six views been around for a while it was a 1.0 that was on the I think it was 2015 that first came out but there was a pretty fundamental change in the way that the library was put together so when it got to version two which was I can't remember the exact date it was about August last year I think all three these were late last year basically it reached a real level of maturity to the library and if you've been following where these have been going in terms of popularity view is on the up and the reason for that is because of the work that went into it so yes it did only go live late last year for production but the development cycle has been very solid with a lot of like good responses if you look into github and you have a look at the number of issues raised for it it's looking pretty healthy so views all right even though still on our fail list Aurelio pretty much the same they had a very long development cycle is very open so you could start playing with it for a while and this is why people get confused when we say it's like how is it only reached production ready just recently it's because that development cycle has been very good angular 2 burns everyone along the way because they changed tack halfway through development if you're a dotnet developer and you've been playing paying attention to dotnet core microsoft did exactly the same thing along the way with that which makes me glad that I'm now working on react and not dotnet that I was for a long time so that's the basic level of support the other thing beyond that is community making sure that if I ask a question on stack overflow because I've given up on life that there will be other people out there who do that this can be hard to gauge but you usually see metrics on the number of projects that are in github that feature a certain library for example so few is rising react is very solid angular 2 I don't know it really is kind of okay but for us it just they weren't enough reacts basically one again because it's been around for long enough that everyone else out there more or less is running through the problems that we might and that helped immensely the last one and the absolute sealer on the deal was as I mentioned at the start not one of us had any experience coding in any of these other planning around with them in demos we needed to hire people fast we had three months to rebuild the major application we probably needed six to do it I had to hire people really fast we didn't want to get to the end of it and have to refactor all the code we wrote because we suddenly learned how to write it like just before it was due so we actually did an experiment on this we narrowed it down we wrote off angular 2 at this stage because it clearly wasn't going to be a fit for us so we put out job ads and we basically went to hire on equal terms everything was the same except we said few or a really or react to see what we get we had zero zero several and I had some great developers out of it I looked further to see if anyone else was hiring along those lines to see if there was something zero zero many it was a bit disappointing to reach this stage we kind of wanted a bit more of a contest because view is really nice really is really nice angular 2 has got its strengths but in the end because of the position that we're in it was just a hands down the react was the way that we wanted to go I wanted to have a choice I really wanted to say I really like this library a bit more on to a few other things dev tools and testing if you don't have browser dev tools and you know you know single page application architecture everything's happening in the browser and you can't analyze it you can't develop that very well I found out when I was trying to debug IE 11 recently and there's no dev tool for any of these in IE 11 it's not easy you have to basically search line by line through the code as this is in debug mode says every bit of code that's in there it was not fun testing every single library support sees so yeah there wasn't really much of a thought about it some have better testing methods than others I admit that I'm not that great in understanding how unit testing works as much as I should because I'm just not a very good developer maybe and I know that especially for really apparently the testing tools are really strong like the integrated testing is really good but from my own limited understanding they're all on the same level I've been schooled by a couple of the developers of these frameworks since I published my article so yeah it's been quite useful to learn that we were kind of on the same on the right track hands-on was really important once we this is we something we did at the same time we put the job ads out because we had to move fast we couldn't just sit there and say well you know leave the job ads up for a couple of weeks because we didn't have a couple of weeks so we gave ourselves two of us picked the framework one went with React one went with Aurelia and we gave ourselves a goal of building a login screen to our current system so we had the API set up we had to do authentication we needed to render the screen and get a basic project set up we were surprised by this in that they both like all these libraries more or less are using the same like ES6 level JavaScript even if it's getting into TypeScript or something like that they're so similar that development was pretty much the same there are differences React with its JSX has the HTML thrown in there with the JavaScript and other libraries don't do that but in terms of the development experience it was pretty much the same for us within the demo cycle setting up is obviously much harder and react than actually I've got the Angular one but that should be Aurelia I'll just buff that up so that's no you did not win it really isn't all right it's the wrong time to find out I've made a mistake there but it really didn't make a difference for us and that that kind of helped us when we're looking at the hiring thing being so important in the decision it's the final result you know every time I do a talk somewhere I have to have a cat picture so if you can fight this this is your drum roll even though I've kind of told you that react one you'll be sitting here and you'll say like we're using Angular 2 we're using View or Aurelia but this is my library and that's good the difference for us is we had our constraints the key ones is we're enterprise we have to be able to sell these things to 12 countries we need to sell the company in a state that someone will come along and offer us a billion dollars and not be frightened because the framework of a built-in doesn't exist anymore so our decisions are a little bit more cautious than something else that you might make for your own projects if I was going to something that I wrote for myself then it would be a completely different result well maybe maybe I go with react anyway since I now know how it works but certainly for us react was the hands down winner I mentioned that I've written about this and so this is a problem this short in URLs is but that's probably harder to write than just googling the thing if you jump onto the site point then you can read everything that we went through hopefully in a more coherent way than the way I've been speaking about it tonight so please do so otherwise you can ping me on twitter I will pop the slides with the corrected bit that doesn't show angular thank you you talked about three pretty important tactics that you used one was to check out the like status of the projects on kithub another was to build a test project a third was to set up like I don't know if we had any kind of we would have been to be done and to get jobs what are some other or maybe can you go into more depth on the like specific things that you did to look at or it's one of the three which is the most important ones to you yeah and the maturity was probably that that they had to have that support it's like I said we needed this thing to survive for three years and it's even though we tried to be as scientific as possible it gets very non-scientific when you get down to that kind of thing I think ultimately like even if we had a framework we didn't like as much and we were able to hire on it we might have gone with that because we had to hire fast I've hired I think seven people you know six months and we needed that maturity and as I've found out the people that we've hired have come in and said like you don't know what you're doing here's how you do it properly we had to do that really quickly um so that that was probably the one thing if there is one thing that made the difference for us um my question is similar on the sense that what if I three years down the road or then grow more mature hopefully the maturity question is longer you play which will you choose because the maturity was the very dominant decision maker yeah um asked me in three years because then we'd be doing I mean our requirements might have shifted three years from now hopefully offline or something that's this native the monthly performance issues because um this is one of the things React is a bit of a dinosaur compared to these other ones so being an old project isn't always good but then React Fiber is new and coming out in the next version of React and that changes things again so making sure libraries in some way up to date and not a dinosaur is really important um and that that's a big risk like you you do risk when you're going for something it's been around for a while that it's just going to stay where it is and it's very fortunate I think with react that Facebook aren't happy just to sit with it they're pushing it forward and one of the key things on maturity that I didn't mention here is um I think I mentioned in my article looking at where a framework is used because you look on the side and say where are you used by hey pal we're used by this and that um who's writing it why are they're actually writing it one of the things that really irks me with Angular is it's being written by Google it's using TypeScript because Microsoft threw a ton of cash at them and Google do Google use it for Gmail? No. Do they use it for Maps? No. Is it on the pipeline for those? No. Do they use it for search? No. What are Google writing it for? They've got a long list of all these apps of theirs that they use it but the chances of using it are slim. Google Analytics? No. So what are Google actually investing in this for and honestly I don't know. React on the other hand is the basis of Facebook. Facebook as it is would not exist without without React. Facebook write it for themselves the fact anyone else uses it is nice for them. Others like you it's a community driven project there's no major sponsor behind it so the success or failure is always going to be a bit more interesting. They're really the same thing it's a community driven thing I think it's one of the old React developers sorry Angular developers on there correct me who wanted to shift out and do something else so it's got a nice heritage in there but at the same time it's running off community which is fine because without community we wouldn't be using what we are but at the same time it's you know you've got to think a bit deeper about like where the money is coming from basically and what the interest is. With Angular 2 fails for Google what does it mean for the company? You know it's not much. If React fails for Facebook the company's gone. There's a big difference there. I think it was first. Yeah you mentioned Filer on that scale a little bit that Facebook is basically rewriting the whole thing because that failed for Google from one to two and in terms of how it sounds a little scary. Yeah the thing that Facebook have done right is they announced Fiverr a year ago. There's a couple of my colleagues that shared an article on TechCrunch which is from today that Facebook have announced Fiverr to the world and no they haven't it's been around for a year. Every single time Facebook have had any developer anything they've been flogging it and trying to make sure people understand what's going on. So when we dived into React one of the things I find annoying as a HTML purist is you have to wrap so many things in divs or something like that it's just really odd. Fiverr fixes that I'm solved right there but they've explained their process clearly. The documentation is already there they've followed the same path and they haven't veered from it because they've just felt like it or because suddenly they've they've hit like they've gone off the wrong track. I mean that's Angular 2 where it's been derailed. Had a great idea where to put the framework but it just didn't work and what they've done is instead just leave Angular 1 behind. So Fiverr doesn't seem to be going that way and Facebook have been through this themselves internally. So they know the pain they know what it's like to have to transition from React 15.5 to 16 so they will have learned a lot of lessons for us hopefully. Does it scare us? No because if you're in this industry you need to be able to adapt to change anyway it's part of it. Like if you're still using jQuery 1 then your site's probably been hacked 20 times by now and there are plenty of sites that still do because no one ever updates anything. Yeah other question out of curiosity what do you use for state management? Redux, yeah don't ask me too many questions about it because I'm an engineering manager and I don't do that much code environment. But that is cool, yeah. So my question is related to the previous one. Can you tell us what you used before and why whether you show stuff or to say like no more you can't use this to move on? We wanted to go for a single page architecture. My experience I mean I've been a developer for over 20 years so I've used a lot of different things. I've got a lot of .NET experience so ASP.net classic. Most recently like Razer I played around with .NET Core which is Razer again. That's pretty much my entire front end career like that and trying to make it render the HTML properly please. But it's all static, server driven architecture yeah that's my entire history. So that's what the product used before? Oh that's CXAs? Ah right. I do that. Yeah yeah, deadly laundry time. There are two existing architectures in place in a company it's been around for three years so you know things have gone wrong along the way. The first one uses .NET backend and has an XML driven HTML generated front end. I've never seen anything like it before. So you'd have to write that off as a completely custom framework. I've done a lot of work on XML and XSL. I've never seen anyone rendering an application in HTML doing it that way. It's bizarre. It looked quite popular in the old ones. But to render your front end like using .NET like it's just yeah it's ugly. The rewrite version that never gained enough traction failed was using... And on the client side? Yeah client side. It was using SBA architecture at one of the old ones and I can't remember right now what it was. But it was basically and that was our other benchmark looking at this old architecture. It stagnated. That's always the risk with any library. The developers on that project had moved on to others and there were not going to be any new features on it. It did pretty well in our assessment because I did include it even though I haven't included it here. But it just like there was no real future. So you're sorry to change the server technology as well? Our server technology is the same. So we're API like .NET API driven. Yeah we didn't want to change everything. Yeah okay I'm front-end. Any other questions? So I've got one question. You did not consider Amber? Amber Jess? No. We had a really short time to look at it. It wasn't on the radar. None of us have been paying attention to the project that much. Yeah I met the guy who's responsible for Meteor.js and he was recommending to view. And but having like talking to the framework authors and finding out what they think is really different from talking to other developers. I was really lucky to be able to ask him and get some ideas from that. And there was conversations like that that led us in this direction. And not everyone's going to like know the person who wrote Meteor or whatever else like that would be able to talk to them so easily. Mind you tweet these people and they'll tell you. At least you're pretty honest about what's going on. Thank you. Thank you.