April 4, 2018

Why Choose React? (Part 2) A Conversation with Brad Kowalczyk

This year marks the 20th anniversary of atmail delivering innovative email software. The original version of atmail was written in Perl. With support for object-oriented coding and a module that embedded the Perl interpreter into the Apache web server, Perl was an obvious choice for the type of web application atmail was at the time.

But, as more people started looking to the web to manage their email and web technologies started to evolve, we started looking at PHP for our next and fifth major version of atmail. We took advantage of PHP’s new features and more advanced object-oriented programming.

This worked well for atmail, but a homegrown, object-oriented (OO) code structure was laborious. So, for version 6 of our email offering, atmail adopted the Zend Framework to keep things organised. This new Model-View-Controller (MVC) laid the groundwork for a larger team of developers to work on the product and push through into atmail 7.

 

Time for something new

Fast forward to 2014 and the way people are using their email is evolving rapidly – and with it, the need for a webmail client that was a true client. Something that loaded fully into the browser and utilised API calls that returned data. No HTML or JSON with embedded Javascript commands to run. Just data that atmail is able to render directly into the UI as required.

One of the people instrumental in seeing these changes through, is one of atmail’s senior software engineers, Brad Kowalczyk.

Brad came on board as the lead developer for the first code rewrite from Perl to PHP. He worked closely with company founder Ben Duncan to create a new version of atmail that had the same feature set as the existing one, but with a complete refresh on the back end. Not an easy task and it was this kind of experience that put Brad in a great position to help lead atmail’s development team in another major change, atmail suite (the 8th version of our email product).

 

JB desk - atmail - Why Choose React? - Conversation with Brad Kowalczyk

 

 

Why Choose React? A conversation with Brad

Session 1: We sit down with Brad Kowalczyk, Senior Engineer with atmail, who has been through many of atmail’s innovation cycles…

(Or click here for the full interview)

[pullquote]We really wanted something where the client was the client and the server was the server and there was complete separation between the two.[/pullquote]

 

JB: I’m sitting down today with Brad Kowalczyk, one of atmail’s senior software engineers to talk about React. What it is and why we use it with atmail. Brad how are you today?

BK: Yeah, I’m well thanks Jason, how are you?

JB: I’m doing well thanks. So you’ve been with atmail for a while now?

BK: Probably been full time now for oh, since 2008. It’s been a while.

JB: You were brought on board initially to do the PHP rewrite of the Perl version of atmail?

BK: Yeah, that’s right. So up to version 4 was written in Perl. My first job, or my first coding job, with atmail was to port it from Perl to PHP. That was version 5 – I believe was the first PHP version.

JB: Then we made a change, we still stayed with PHP, but we adopted the Zend Framework, so it was pretty much a code rewrite to move from the kind of home grown object-oriented PHP we were using, to a more formal MVC type of a system. With the rewriting of the code from atmail 7 to atmail 8, we took another pretty drastic turn to use React on the front end.  Why do you think we made that choice?

BK: Yeah, we’d been talking about changing our architecture if you like to be more of a true client server set up. So that the webmail client was simply making API calls. We really wanted something where the client was the client and the server was the server – and there was complete separation between the two. We could update the server side of stuff without impacting the client, that kind of thing. As long as the API stayed the same, we’d be okay. We really wanted to move towards that client server architecture. So about three years ago, I guess, we started down that path. The obvious choice was to use a Javascript framework or library that was designed for that kind of thing, for building single page apps if you like. It would then communicate with a server or web service for it’s data.

JB: So, React powers a number of, you know, really big applications out there in the world – Facebook, Instagram. So, now that that was public, was part of the idea that this was going to be around a while?

BK: Yeah, well that’s right.  It’s used extensively in production. And not just any production, but as you say, big time production stuff like Facebook and Instagram. It had a lot of momentum and sticking power. We thought it wasn’t just going to be a fly-by-night thing that came and went.

 

 

Session 2: We continue to speak with Brad about how React gave us a bit of a head start on development…

[pullquote]We couldn’t take two or three years to do this. It had to be done pretty smartly, pretty quickly. So, React’s Material-UI really gave us that leg up to get a prototype up and running really fast.[/pullquote]

 

BK: Another bonus for React was that we’d already made the decision to use the Material Design concept for our UI. It was a great project Material-UI that many would know that was a React package that gave us access to a whole host of prebuilt components that had been built using Material-UI design concepts. That was also something that gave us a big head start in building a user interface. So, that too was something that kind of prodded us along towards using React.

JB: It sounds like this was a real time saver for us. Both in the time to develop and in the number of development hours required for this kind of project?

BK: Yeah, well that’s right. It was just a really great starting point for a user interface. Just having that library of prebuilt components that Material-UI offers was a big bonus to get a leg up. We couldn’t take two or three years to do this. It had to be done pretty smartly, pretty quickly so React’s Material-UI really gave us that leg up [to] get a prototype up and running really fast.

JB: How long did it take to go from, you know this is the direction we’re going to go, to we’re ready to roll this out as a production product?

BK: Yeah, great question. I think probably we probably had a prototype with at least mail and contacts working within probably I’m thinking a six month period.

JB: That’s a big head start into redesigning something like this from the ground up.

BK: Oh for sure. Absolutely. There is some learning curve that goes with it. So, just getting used to the new paradigm, the way React does things and the way you need to think about doing things in React, that took a little bit of getting used to, but once that penny drops and you’re thinking in that way, React itself is really quite straightforward. It takes so much time out of developing a UI, it’s crazy. Not having to worry about manual DOM manipulation is a great help.

JB: Let’s talk about that a little more. That’s one of the big things I saw working with React, is the virtual DOM. How is that better?

BK: Well, basically, we don’t have to worry about manually finding a DOM element using jQuery or vanilla Javascript, whatever you want to use. We just didn’t have to worry about finding that element, making sure it’s the element we actually want, it’s not some kind of selector crossover, or we’re actually selecting the wrong element because there are two elements with the same ID or something like that. Not being specific enough. Then you have to perform the manipulation and often you need to check what state it’s in before you perform the manipulation.  Like if it’s a toggle, if it’s on, we’ve got to turn it off, if it’s off, we’ve got to turn it on. All of this kind of stuff, you have to manually manage and handle. In the old way of doing things, with atmail 6 and [atmail] 7 and [atmail] 5 previously to those two. When we were using jQuery, it is just a lot of having to manage and know the current state and manage the state of the DOM and you can imagine when you’ve got files with jQuery scattered all over the place, you change something in one file or manipulate something in the UI somewhere and some other code somewhere else could then break. Whereas with React, you just kind of don’t have to worry about keeping track of any of that stuff. You’re writing components, they have props (properties) that come in, some of them may have an internal state as well and when the data on the props on the state changes, then the UI automatically changes to reflect the properties or that state. Compared to the old way of doing things, where you actually have to manipulate the DOM itself, it’s just far more straightforward, far less room for error and making mistakes. It’s just far, far better than jQuery spaghetti sprinkled everywhere.

JB: But that being said though, it’s still, a the root of it, you’re just writing Javascript.

BK: Yeah, exactly and that was another bonus with React, was that it was just Javascript. You’re not having to learn or introduce some other templating language into your stack. It’s just simply Javascript, so if you know Javascript, you can pretty much just write React. There was a little bit of a learning curve with JSX. We hadn’t been exposed to that before. So, rather than having a templating language that is limited in the power in any logic that it has to decide on what to display or that kind of thing, JSX just introduces the templating into Javascript it sort of turns everything on it’s head. So with JSX, the template if you like, or the mark up code, is in the Javascript rather than the other way around. So you have all of the power of Javascript.  Your conditionals and working out what to display and all of that kind of stuff.

 

 

Session 3: We finish our conversation with Brad, asking what the future looks like for React and atmail…

[pullquote]I mean it’s not trying to do everything. It’s just focused on a specific task if you like and it does it really quite well[/pullquote]

 

JB: React gives us the ability to use Native to create a mobile app.

BK: Again, that was yet another positive that we looked at when we were trying to decide on what to use for atmail 8. React Native was a big plus. All of that knowledge and skill set that we built up, we can then reuse rather than learning a whole new language or a whole new stack in order to develop a mobile app. We can use what we already know. So, that was a real bonus as well.

JB: What do you think React looks like in general? Is this something we’re going to continue to leverage? Are there new things coming down the track that you think React is going to lend itself really well to, or do you see that we’re only going to get to a point and then we’re going to have to make another critical decision to go with something in addition to, or something else?

BK: Well, I think React is leaving us a lot of space to develop in the future for sure. And again, I think the fact that it’s only concerning itself with the view side of things really, I think that really makes it something that just isn’t going to go away in a hurry. I mean it’s not trying to do everything. It’s just focused on a specific task if you like and it does it really quite well. It’s not trying to, you know, do what Redux does. You’ve got things of Redux that can take care of what it takes care of – and there are a bunch of libraries that do a similar job – and you’ve got React that takes care of the view side of things, the UI side of things. I think just that fact, that it’s very focused on the job it’s doing, helps in that sense in that it’s more flexible for people.  You can get more people using it because they’re not tied into using all of this other stuff as well, that perhaps they’re not interested in, or they don’t like the way it works.

JB: We’ve been speaking with Brad Kowalczyk, one of atmail’s senior software engineers. Brad, I want to thank you today for taking the time to provide us with some details and some insight into how we’re using React and what we’re doing with it.

BK: Yeah, my pleasure Jason.

JB: Decisions like this, major changes in architecture and complete rewrites to a user interface, always pose a challenge. It is my hope that by sharing a little insight into the, “Why choose React?”, it can be helpful for others in a similar situation. A great thank you to Brad for taking the time to help us understand just a little more.

 

 

Why Choose React? (Part 1) An atmail Perspective

If you’re interested in reading the first part of this series, please click on Why Choose React? (Part 1).

Highlights include:

  • What is React?
  • So, why choose React?
  • Code Reusability and “It’s just JavaScript”
  • Reducing coupling and increasing cohesion
  • React is FAST! (includes diagrams)
  • The philosophy of change
  • Pete Hunt video

 

 

Want to learn more about our React-based product, atmail suite?

We invite you to check out atmail suite here and send any questions our way here.

 

 

Full interview option with Brad Kowalczyk

If you’d prefer to listen to Brad’s full interview with just one click (rather than the three parts separated above), this option is for you:

 

 

Share This Post