 Bugly I checked out the definition this morning. It actually means but ugly So but I had it as buggy and ugly but What I want to do is just share a hard truth with you always that fundamentally we build extremely buggy web applications and we as in you and There's many reasons for it. There's many reasons for it. One is Logging is so complicated. So we build a big fortress and put applications behind it and Features behind it and Because it provides some sort of sense of security We go from building apps really to building really large fortresses You know you go through of this big gate this moot this security Gate and then all of a sudden you've got access to everything That creates an extremely slow archaic large Want to be web application, which is really a website with a whole bunch of proprietary Glutton inside it They're expensive extremely expensive and as an architect at ING we have this discussion all the time. We want to Refactor but refactoring comes in extreme cost We want to move from one framework to another and it requires such a big move that we end up having Really a Frankenstein of frameworks many of them. It's not really this one. It's not really that Also, it's extremely slow because it's so large And if you take a look at the websites that are being built today and even the ones that already exist They're extremely large and disruptive So it's not good news actually, it's so bad that That there are people in the community that actually have websites that track your websites One for example is Aussie outages calm This is a community where they are monitoring the availability of websites and the Essentially the bad experience of websites in the finance industry and the top four banks in Australia Collectively only offer 91% availability. That's 33 days Where they're out in a certain year 33 days you can't bank in the country That's scary, right? 33 days, it's huge And the best part of it all is that they tell their customers on Twitter. I guess what we're knocked out for the weekend So plan ahead God help you if you get a date or something like that. You're in trouble because sorry, baby I just got for $40 So this is part of the problem and and it's almost like it's okay It's almost like it's all right. We're using jQuery. It's fine It's okay because we're with we're using Redux or whatever we're using embo or something like that And what I'm trying to highlight is that all of that largely is fundamentally from a business point of view irrelevant But if you take a look at the growth in the transfer size You'll see that most of our applications and essentially our pages are growing Dramatically, there's an organization called HTTBA archive who actually trends your stuff, believe it or not there are people that actually find this stuff fascinating and The size of a page now a total transfer for a page because these aren't single-page applications It's the same size as doom the game who played doom You've all I know you all played doom all right and Doom ships with its own 3d rendering engine believe it or not has its own weapons and a whole bunch of stuff There's some really good nuggets and Easter eggs inside it. All of that is actually 2.4 meg That's the size of a page that we're downloading today every time a customer goes to a banking application or any application to be honest with you Because if you take a look at these guys, that's what they're saying It's a doom every time strange But that's okay. Guess what there's more to law If we can't fix it CPUs will It's okay. The customer will get a new phone that will go faster on their phone and actually There is some science to it. There is some truth behind it because as you can see here some Organizations have been publishing benchmarks for for the new iPhone 7 and it does perform extremely well but for every law there's an anti law and What's law? I think some people say it's pages law and gates is law. I don't even know Fundamentally saying that the software efficiency due to codecraft feature. I just a whole bunch of other stuff Hives every 18 months anyway Actually, there's another reason it's fundamentally because we build applications to build our resumes What we do is like bubblegum we go and we say okay. Here's a new framework I'll chew on that for a while and when the taste goes. I need a new one I'll get a new job with someone else and leave this big application here Yes, yes And so what happens is we end up with this big fat monolithic monster in an organization That the new developer looks at it and goes I need a framework Note the loop and it obviously ends up having excessive refactoring. We have a Frankenstein a proprietary opinionated Implementations it's extremely not shareable It's silent. It's a mess and fundamentally to be honest as front-end developers There's a law called Conway's law and you I'm sure you all know it We all read it all the time But basically says the communication channels of the organization will fundamentally reflect in your application Yes, we try to solve everything in the front-end So the front-end gets bigger more frameworks and blah blah blah But when we talk about architecture fundamentally, we're talking about Code organization, whether it's MVC or something else. We're always talking about code organization, but the unit of change is still the application Mergers are expensive. They're difficult to share. It's extremely complex Composition is difficult and we end up with the mess So let me give you a real example Let's take four scenarios banking scenarios account opening move money bills and transactions The company says okay, we want to do a project on move money. That's okay And so we do an assessment we take a look at the channels the front ends We take a look at some of our services We take a look at the core at the back end then possibly we take a look at some platforms and some some operating Systems and we come up with yeah, this is an approach. We're going to do it this way But what we discover in which we all knew is that the core makes assumptions about platforms The services make assumptions about the core and then the channels make assumptions about the services and fundamentally We have a really big big project That's okay. If you're doing one The problem is when they want to do the bills project And when they want to do the bills project There's a lot of contention bottlenecks and ultimatums that have to be made and essentially 1 plus 1 ends up equaling 3 That's why it's not just fundamentally an estimation problem because we all say hey, you can't estimate Development okay, you can't estimate but also accept the fact that we have crap and Because of crap crap on crap makes a very big and difficult way and way to estimate so the last part of this tragic story fundamentally is an Event happens whatever it is It could be a new framework such as such and then a hero pops up and says Great idea. Let's adopt another framework. I'm going to build it a modular framework Which dr. Carlos Brown in a book called design rules actually did one of the biggest assessments on modularity and Fundamentally came to the conclusion that we all intend modularity, but it's really a monolith And then we end up going with different opinions because as time progresses We we end up adopting different opinions it becomes buggy and then we wait for the new event and that new event typically is when the developer leaves or A new framework comes out and then it comes really really fast so Is the problem the the languages or is the problem the platform and as sir Alex Russell says the problem is Fundamentally about the platform and I'd like to add the source of the people So the web needs you The web needs you to get serious about being a web Developer and if I'm doing anything what does it what does it mean? What does web mean? It's actually means that you're a standards-based developer so you need to take a look at new use cases and once you find new use cases work with those new use cases and Basically converge on certain agreements on what those primitives could look like and also abstract them out so that we can start using them with polyfills or something like that and then when the industry body Sees and understands the value we create they move them into primitives and into standards But we have to let go and go to the next one not continually for fight over and over again And the things like the extensibility web manifesto is actually starting to do that and promote that type of language in that type of thinking So what does it mean? It means that true beauty is on the inside It's not just about how it looks, but also about deep inside how it works. It has to be performant So at ING we take Google Rails seriously so serious. It's actually become the criteria for our non-functional requirements Yeah, so we now have very specific criteria that the responses have to happen within a hundred milliseconds Applications have to be less than one meg They need to be secure. I won't go through this security standards, but what I will do is this Guys security headers.io scan your websites and take a look if you don't get an F. You'd be surprised Seriously banking sites most of them and I've scanned most of them get score an F And F couldn't mean a few things depending on how you take it Also build your applications to be immortal and what we mean by immortal is that it's not just that it's bulletproof in the sense That it never dies, but it's also long-living So adopt and embrace standards Use the platform for what it is Push the state to the client not in the server Because the ultimate state is the user build offline first Unplug your cables turn off your Wi-Fi and build like that and try to make sure it works offline first handle failures and be and go with the progressive Applications but also when you're going with modularity Understand that we want it. What does modularity mean? It means that we have to make it design time independent that I can work on this thing independently of the of the whole But at runtime it's got to work interoperably So it frees me at design time, but at runtime it works really well as a member of the wider community of components So now the unit of change is the component. It's not the application. It's the component And when the component is the unit of change we assemble applications based on components We don't develop applications anymore we develop components and From those components we can assemble very different business functions For example at ING we say that the customer service team that answer phone calls Need to see the same experience that the customer sees on their mobile or on the web To me it sounds like sharing components Yeah, the only difference is one component is embedded with a telephony so that with telephony features so that they can answer phones The other is not so our definition of done This is what we put down as a quality criteria for a component Every component in the bank must have its own repo It must have its own lifecycle and it has its own repository. It's built with internationalization out of the box It's built with accessibility out of the box. We no longer debate whether those who have partial Vision or vision impaired are some sort of subclass customer We expect it to be accessibility compliant day one Also, the tests are baked in day one the thing works There's even a demo and I would go so far as to say that we need to move towards some sort of Demonstration driven development not just test driven development get the demo in the hands of the developers as quickly as possible Show your stuff works We've even gone so far as using blueprints to mock the API's at the back so that custom elements now have a one-to-one relationship with API's and We've actually produced a documentation and this is clear criteria for what we call ready based components for consumption by the next developer So when we take a look at the architecture most banks and organizations were or are still unfortunately in the big blue box and Some are having discussions about moving towards a client server based mainframe still back-end database scenario and The rest of the world is stuck in this hole now where they're taking a look at the middle the middleware and API's and so are and having discussions about microservices, etc. But we see an opportunity We see that the opportunity is Potentially we see the micro service movement, but our ing we've gone one step further We've predicted that the world will fragment even further and our architecture needs to look like that We want to have custom elements with the main base services at the back and Those the main base services can be part of that customer element that custom element scope and now It means when you ship a custom element to another team. It also comes with its API's Not only the API's for component interaction, but also API for back-end interaction It goes a little bit further We also have to take a look at the way we do API's because we want to minimize the number of chattiness between components and back-ends So our responses are now rich responses and it means that when I move money I Also get the balance back and the list of accounts So I don't have to do subsequent calls to get hey, what's the new balance and what is the latest accounts of the customer now? With the response I can do some data binding and then publish the the new balance to all the components that need it and Fundamentally means 50 50% less IO, but it also means I now get to use data binding the way it should be used So how does it look? It's a technical summit. So let's talk about it Fundamentally we produce the API's Automatically because we have mocks and and and and interfaces We have them very clean We know what they are and we now have an outside-in model where we work with our business and say what do you want? The API is not driving the application or the component the requirements of the business and the user is driving the API And we generate the API's because let's be honest. It takes forever to wait for a back-end person to give you an API Yeah, so stuff it would just build it ourselves Conway's law and When we get the API's the response from the API's very simple We update the the variables in our store and you can see they're all custom elements and the data binding then becomes available to all the components that are listening and The process repeats itself over and over again And if you notice the actual system is extremely simple. It's so simple that When you think about it, it's actually an end-to-end working system of a collection of components our entire digital front-end particularly in In ing if we take a look at the Australian scenario is completely web components and custom elements. There's nothing else There's no frameworks. There's no additional libraries, etc. Etc. It's fundamentally just a whole bunch of custom elements and we use BFF which is back-ends for front-ends in order to To abstract those those API's and make them bound to the to the custom elements But what's important is that our API's are not cattle We're not stressed about the API's themselves that way you have interface and contract based Experiences the API's fundamentally reflect what the customer requirement is So they're not pet. Sorry. They cattle API's fulfill the demand of the experience and we come to the understanding in the agreement that poor back-ends also equal poor front-ends So you have to fix your back-ends as well You can put a nice custom element in front of an Assistant and give that in the hands of the customer, but if your back-ends are crap, then your front-ends are crap So believe it or not I've heard Taylor and Matt say over and over again doesn't element for that doesn't element for that Well ing there is there's 350 of them that are being used and our friends all over the world Including the Netherlands and Germany and Belgium, etc. Are building custom elements for the group to use over and over again The number of API's we have that are being used. Honestly, I've lost count and to be honest I really don't care so long as it returns the data that I need and it's bound to the custom element We're fine If you take a look at it there every application that you build at the front end needs some visual components and rich visuals some Navigation utilities and customer features most of those we want to source from the market We don't want to build everything ourselves whether it's a telephony component with Tulio or it's a Charting component with VAR then it doesn't matter if it's available in the market. Go get it Ship it as a custom element and we will build the pieces that are in the gaps the stuff that's specific to us banking So we're assemblers first and That's the key message We are assemblers first being an assembler means going to the box of Lego find the Lego piece you need and then put it Together don't go build your own and most developers love file new and we need to move away from file new and go into the box And go to the repose and find one that makes sense read the markdowns There's a reason why we've written them and We're craft people second if they're not there then we craft So what does it look like at runtime? Well, fundamentally, we have single-page application That's HTML 5 and we have two files our entire application is two files index.html and ing.js Only data ever traverses the network. So all you ever see when you look up the The network you see the X HRs just going across state essentially managed and into the client and All the business logic what constitutes business logic is in the back in the data center And there's a reason because data centers have 40 gigabits per second networks So we push all the service aggregation and service composition into the data center where it's faster So the front end is extremely light and extremely thin So you need to break Conway's lure a little bit and have a conversation with the people in the back And if they don't want to respond then do it yourself What is our runtime metrics look like we've been running? We've been working with polymer since point five and we love it And when 1.0 came out we were ecstatic and now in this current state This is what it looks like running a runtime the industry average if you look at GT metrics for page speed is 81% ing is at 98 Our page load industry average at 5.8. We're at 2.3 and that's not good enough as you can as you know from the Google rail discussion Our page size the industry average you heard earlier is the size of doom ours is 538 kilobytes. That's the whole app That's everything and The request industry average for requests believe it or not is 69 and with htp1 htp1 It's actually at 2 so it becomes even worse in terms of serial requests and ing it's 9 So now what does that mean? Let's go back to this scenario when we do move money and We do the transactions project. They're not coinciding and they're not contending for resources Bills can also go in parallel as well and have more concurrent development. In fact, we can have a lot of concurrent development Because the architecture is broken up. We don't have a monolithic per se a monolith per se But the real advantage of all this is that we have a culture of motivation people are autonomous Because they can do it inside their component They have purpose because they know they're working to a business end in a business goal And they're also masters of their domain because they can use the right technology for the right function But why web components? I get this question a lot ing bet on web components really early Apple said something along the lines that They are the web standards are the web Yes, there's lifespan benefits. There's parallel delivery as I said earlier time avoided There's also the value of business options the fact that you can mix and match and imagine what scenarios you could do If you can take one component into another business stream But really from my side, I actually want to talk about the facts Again the polymer team has been saying over and over again that use the platform use the platform use the platform So we went to github and countered the lines of code. I've thankfully they actually offer a function that does that and I Think the chart speaks for itself There's four times more markup With polymer than any of the other frameworks that are available and there's 10 times less JavaScript This is over three years Or three years since the inception of polymer That tells you volumes If you want to be a JavaScript developer and you want to solve platform problems with JavaScript You will have a problem with polymer But if you want to solve true customer problems with the web then polymers your choice So final slides Learning and unlearning What we found is more people are framework developers than they are actually web developers So we had to teach them HTML 5 again. Sorry, but it's the truth. They don't know what immediate queries We don't know what sections are and so on and so forth Also, you need to build a lot of automation with your tool chains to make their lives a little bit easier You need to offer samples and guides But probably the most important thing is get them to assemble something first not craft something assemble Build their first component second and then finally evolve it if you can't solve it. Thank you