 So I'm in the middle of migrating a pretty complicated web app to Ember and I thought I'd share some of my experiences with you So I Work for claimable We make basically a web application for the insurance industry. So it's very niche very specific to be to be out and it basically helps Insurance companies manage the entire claim process. It's very process driven. The current version looks a bit like this Not bad looking for a business app, especially an insurance industry app These guys are hideously underserved when it comes to good software You'd be amazed at how many of our clients still use fax paper Excel spreadsheets and to think these guys run our economy It's pretty scary But this is claimable in its current form it basically lets The the back office staff so the claim handlers process a claim so the idea is that it's a smoother experience for the policy holder or the Person making the claim basically so you can see it lets people upload documents take notes that kind of thing It is written currently in cappuccino, which I don't know if anyone's heard of it's a fairly obscure framework It's basically coca for the web And we started using it maybe two or three years ago when it first came out at the time It was pretty revolutionary actually it did some things that Now we're kind of taking for granted, you know One of those I think was bindings And the other one was things like lazy loading and a really good table view component There was a lot about it that drew me to it So it seemed like the perfect thing to use for a big complicated B2B web application like this however as time has gone by in my opinion their direction has Lost focus or maybe it's got too much focus because I think the problem is that they're so religiously fanatical This is the core team members. I'm talking about about Porting coca to the web they've forgotten what is great about a web application basically HTML and CSS So a good example that I always fall back on is Recently well not recently but you know in the one of the final versions of the current current application I wanted to add a just a tag just a link and the way to do that was considered a hack because It was so strictly objective J and coca That you had to drop down into the DOM and add this a you inject this a tag into the HTML in a way that you wouldn't expect to And it kind of frustrated me So I started to look for other solutions and that's where ember comes in Ember So I think at the time Cappuccino was a good choice because it don't get me wrong. It's been great And it's pretty clever to be honest. There's some amazing things it does, but I think it does It fails mostly in one in one place and that is forgetting. What's great about the web The fact that you have to write objective J code the whole time And you don't even it abstract so far away from the DOM and CSS and HTML That it's very difficult to style anything or even for example if you wanted to hand your Your app to a web a front-end web designer. They wouldn't be able to interpret the DOM It injects all these divs all over the place with really weird class names and things So it's pretty unmaintainable from that point of view so I made the decision maybe six months ago to rewrite the whole thing in ember and I thought well, we're Not even halfway through that process yet. So this is fairly Embryonic what I'm about to tell you it's still fairly new. I'm still learning ember I know Cappuccino really well because I've been using it for two years But what I thought might be interesting is if I share kind of these three things that To me I don't want to take for granted about ember. I actually changed the name of my talk I started out with it being five lessons learned and I thought maybe that's too many So I made it down to three and as I started to think about the lessons I've learned in so far using ember I realized that those are actually the things that I started to take for granted and I don't want to so Fairly high level, but the router we all know about this to me. It's like magic. I think it's amazing Obviously, you've got things like it forcing your URL led design, but before that I have an experience with Writing my own. I didn't know at the time that I was writing my own router, but with my first experience with Cappuccino, I distinctly remember the moment where I had a tab working and you could change tabs and it was loading the content and it was all Ajax and then I reloaded the page and Reset to the to the root, you know the root root and I realized that okay, it's my responsibility as a developer to Change the URL and pass the URL. It seemed kind of I guess Expected at the time now in hindsight. It seems ridiculous. So there I was writing this What is probably a horrendous router? That every time I clicked anything in my app it would update the URL and Then pass that when it when it reloaded so for me I think one of the single best things about Ember is this this router and the fact that it forces you to think about your roots before anything else And for a big application like claimable That has to remember state It's perfect because it means that we can strictly Think about the different states the application can be in not as an afterthought So for me, I don't want to take this for granted you get this for free just from using ember So not only does it force you to think about how you architect your application? You get this great functionality as part of the package and you it turns out the users click back a lot So our users are real technophobes that some of the requests we get are crazy You know, it's it's pretty pretty difficult to support actually And they're clicking back the whole time in our current version if you click back It goes back to Google because that's probably what they were looking at before before using our app So yeah, we could we could mess around with the the history API and what have you but again you get it for free with ember So it's great for me. I don't want to take this for granted. It's perfect You know, we're we're delivering what we're promising it comes back to this whole thing about Cappuccino is a web framework, but it forgets that the single most defining thing about a web application or a website It's probably the URL So that's great, I love it and the other thing as well that we've learned is that You encounter all sorts of problems with long-running apps and by that I mean our users typically log in at 9 in the morning and use it All day without reloading Until like 5 p.m. And if I didn't know what a memory leak was before I do now, you know So again, I'm not wanting to Criticize Cappuccino because it's a fantastic framework, but it's huge the memory footprint. It's huge The payload is huge. So we would have these problems on less than ideal Browsers and hardware to be honest that wouldn't help where users would just it would crash It would just they'd get that weird script timeout error thing It was a big problem. So again with with ember. I think it really encourages architecting your app in a URL led way That helps you with all of these other problems that we've certainly encountered So the next thing Backend agnostic It was really interesting to hear the previous talk About how they're stuck with these legacy backends. We're fortunate that we we have our own back-end So we've always maintained that Even with the original version. There's strictly a restful API and a JavaScript UI, but because Because the original version there wasn't really any defaults Well, there wasn't the equivalent of ember data. There was talk of having core data But it never really happened So it meant that you're on your own basically So what we started doing was finding ourselves solving bugs in the UI by just changing the API Which is kind of cheating and it breaks away from that purity of having the two things completely separate because what we want to Be able to do is swap out the API right not only that but a lot of our customers use our API So it needs to be really well documented. It needs to be very consistent and almost So that a developer can discover the URLs without having to necessarily Dig around too much. It's kind of obvious, but we found that previously we had to break that and In my opinion corrupt the API a little bit in order to suit the front end But again, what I love about ember is that ember data means you It truly is back-end agnostic and not only that but it really Respects restful conventions and encourages an API led design, which again for me my I even view the Our main product as being the platform actually the the API rather than just the interface because we have Mobile apps in development as well. And like I said our customers consume our API So it's pretty important Okay, the last thing I wanted to mention was just this general concept of under promising and over delivering it It before I made the decision to move to ember It dawned on me that I was doing the opposite. I was over promising under delivering which really bothers me and I think I'm not just a developer part of my role is also involved with the marketing and The product design side of this application. So it's really important to me to be able to Deliver what we're promising or even better over promise. Sorry under promise over deliver And again, I think ember really helps with that because like I said We had this thing that looked like a native app because it was built that way but basic things like the back button didn't work and Know all these other things that these visual cues would kind of make the user think that they could do certain things Maybe it's drag-and-drop a particular element because it looked like a native app But they couldn't and it really sucked. So I think again by not having this obsession with porting a A native framework to the web and actually acknowledging what makes the web great So URLs and HTML and CSS but bringing in all the things that are good from native frameworks like bindings and things like that components you get the best of both worlds and for me, that's been really a really sort of encouraging approach that has I think improved our Sort of architecture of the of the product and the way we've structured the application And the last thing I'll mention is is just speed So we're used to I think 4.7 megabytes as the payload Which on anything less than chrome on like a decent machine doesn't run very fast Forget mobile So again, I think I'm not going to take for granted how quick ember is I've seen you know blog post about it not being quick But in my opinion it really is and I think what is it 47 kilobytes or something like that? It's pretty good. It's a small payload and you get a lot of functionality for that So that's it really I kind of just wanted to share what I've learned to date. Like I said, it's still in the early stages The bottom line is I really love ember and pleased I I sort of Took that approach and back the right horse So hopefully I'll come back at some point and share a bit more in-depth detail with you when I've gone further down the Process, we'll hopefully by the autumn have something well have it completely migrated as well That is it. Thank you very much We're gonna only be able to take a few questions because we need to get to the pub So when this is all done, it's the water poet it's left and then left and then left again And you'll see it straight there. We'll see you all there, but I was wondering curious That's That's a good question. I forgot to mention that maybe that's a topic of another talk, but in theory. Yes in practice. No Yeah, so I mean we intend to and I think I Don't know personally. I need to do some some research about testing in ember I Don't feel like qualified to comment on it only that I've heard that some people say it's bad Some people say it's really good. I'm inclined to believe the latter. Maybe it's just a documentation issue or something. So At the moment we're kind of Doing it without tests the API is tested, but the front-end isn't But we will that's the short answer. Maybe if I come back and talk again I can talk about testing yeah, because actually one thing That is important is because it's such a complicated application and we have because it's so process driven what our customers do We need to really test things. There's lots of Scope for regression bugs when we add a feature and then it breaks something else. So testing is absolutely a priority Really There we go, yeah Any more questions, yeah That's a really good question I did and at the back of my mind I was very conscious of Kind of making a wrong decision like I said because it's My position is that I'm also running the company as well as developing this thing at the back of my mind I'm always thinking about The business side of things and it felt me choosing cappuccino felt like a mistake basically to put it bluntly And it you know cost a lot of time and resources. So I was particularly sensitive to that. So I did Did make the point of being quite considered about it. I did review just angular really I sort of looked to I did some shallow research into most of them But I knew what I needed it needed to be like a big framework like What am I thinking of Well, it's a small framework but backbone backbone was clearly not going to cut it So I kind of discounted that and just narrowed it down to like and give it an ember And I kind of said to myself. I'm not going to rush this decision. My timing was actually ember comp in March Must be March. Yeah, that was my timing. I booked a ticket to that and said right by the end of this trip I would have decided one way or the other I think in reality and in hindsight my decision was already made one of the big factors was the community I can't Sort of have stress enough how important that is because the cappuccino community is minuscule like really tiny So seeing going to ember comp and seeing the the community and not just the size of it, but how How sort of thriving it is, you know really encouraged me to just take the plunge and say right We're going to rewrite this thing at Ember Doing a rewrite is always a big Question for a business and I don't know in the suit soon thereafter as you start to try to figure out ways There's a way to incrementally bring things in it. Did you ever discuss whether there was I mean seems like there's a lot of up Things that might block that from happening for the you are expected Native yeah, it would be I think it would be impossible with the way yeah with the way that one of the things Cappuccino's really bad at is integrating with any other frameworks. You can't even use jQuery with it really it just doesn't It's kind of a bit of a beast in that regard It's that or nothing Which at the time again, it seemed perfect because it's they even say to be fair they say on their website, you know This is meant for building like native class be up. You wouldn't use it to build a blob or something It's really for this very specific thing which seemed perfect But Yeah, I don't it wouldn't be possible to sort of do a little bit in ember Still have some of it in cappuccino. It has to be all or nothing really I think it and if it was possible, it would take more time and resources than just rewriting it. That would be the clincher So the timeframe for when you're done is as well. Well, I'm aiming for like mid-autumn. So I guess that's like October kind of time I mean one thing that's good about it in terms of the product point of view is that we know And this is what's different to when we were building the first versions We know what it should do. We have all the features and that's not the problem. The feature set isn't the problem Yeah, you know being in 2014 rather than 2012 has afforded us some new features and things But we actually know what we're doing. We have everything mapped out. So it's quite a different process It's more like we're building on what we all of the sort of I Don't know. I guess the sort of The design decisions that we made and spent so long agonizing over we're building on that and Rather than sort of I don't know from from my point of view I think that building an app like this is as much about Taking a step back and architecting it as it is writing the code So the kind of the architecture bit in my mind in terms of the layout the screens is done So it's less overwhelming than it was building it in the first place