Joy Clark: Hello everyone, and welcome to a new conversation about software engineering. This is Joy Clark, and today on the CaSE podcast I will be talking with Lucas Dohmen about front-end development. Welcome to the show!
Lucas Dohmen: Hi, Joy.
Joy Clark: First off, we wanna talk about front-end development today... Could you tell us what front-end development is?
Joy Clark: How would you describe yourself? Do you do mainly front-end development, or mainly back-end development, or both? Or none...?
Lucas Dohmen: I think I do both, and I switch between front-end and back-end between projects, and between jobs... In the job before I started to be a consultant, I worked at a database company and wrote a database. I'm very interested in the Web, and I do everything that's related to the Web, both databases, back-end development and front-end development.
Joy Clark: I hang out with a lot of back-end developers - I've been called a back-end developer at some point in my life - and I think a common misconception is... There's a common misconception among back-end developers that front-end is not as difficult as back-end. Would you have any response to that… odd claim...
Lucas Dohmen: You have to do a lot more testing of different setups than you have to do on your back-end, because normally you have the same setup in production and on staging and on your local machine, basically. This is where the front-end gets very complex. I'm not saying that back-end development is easy, but front-end has its own complexity, and especially good, maintainable CSS is very hard, and you need to put a lot of effort into it.
Joy Clark: It sounds like even in the front-end there's different kinds of architectures... Is that true?
Lucas Dohmen: Yes, that's very true, because there are very different frameworks, and libraries that you can use, but at a fundamental level you have to make one decision, and that is "Where do I produce the HTML code?" because the "classic" approach is to produce HTML on the server and send it to our client. This is how it was supposed to be done when the Web was invented, basically.
Lucas Dohmen: Some people say that this is inefficient, and they prefer to create the HTML on the front-end. Basically, they consume some kind of JSON API, for example, and then they create HTML in the browser. This has advantages and disadvantages, and some people say that this is the “modern” approach... I would disagree. It's just a different approach. Those are basically the two different styles that we have.
Joy Clark: Could you talk a little bit about the benefits and downsides of those two approaches? You mentioned rendering HTML on the server side, and the rendering on the client side... Could you talk about the pros and cons of those two approaches?
Lucas Dohmen: One thing that's a common misconception is that producing the HTML on the server side is somehow inefficient, because you push more data to the client, which is in my experience not true, because JSON is not smaller than HTML, especially when you use something like GZIP, because all the tags will basically be gone from the GZIP version of the data. So I think that they are both very similar in that regard.
Lucas Dohmen: That's why I personally think that the client-rendered Web applications are less resilient to failures than the server-side rendered ones. Reasons why people still prefer that is that on the one hand, they want to have faster interactions. Imagine that you, for example, have a text field and markdown previewer to the right. If you now have the really classic server-rendered version, you would always need to send the markdown to the server and receive it back, right? If you however had a markdown parser on the client then you can show it directly. There's no network between that.
Lucas Dohmen: If you would have authentication logic and executed on the client, you always need to do that on the server as well, because you cannot trust the client to be mangled with or changed with... And this is why a lot of those client-side rendered applications have a lot of duplicate logic between the server and the client, and that's why I personally prefer the server-rendered way. But I see applications where it makes sense... Games, for example, don't make sense for a server-rendered version, or Google Maps, for example.
Joy Clark: Interesting. We did an episode with Jen Simmons (episode number one of the CaSE Podcast) for anyone who's interested in hearing more about CSS; I think that episode turned out pretty well.
Joy Clark: So there's the server-side rendered apps, and the client-side rendered apps, and I'm thinking about how does the -- when we're developing Web applications, we're talking about front-end development... But does that mean we get to ignore the back-end completely?
Lucas Dohmen: Yeah, that's one of the reasons why some people want to do client-side rendered applications. If you have developers that don't want to interact with front-end, they just want to do back-end, it is a very easy way to just say that "We have an API, and this API produces JSON or XML or something" and then there is a (separate) front-end team, and that talks to this API. And then we have a very clear cut between those two teams.
Lucas Dohmen: Some people think that's desirable, because they want to have a fancy microservice architecture with 500 services, and our front-end talks to those services. But I think that this kind of architecture is a product of an architect that doesn't think that front-end is a complex topic. Because why would you cut your back-end into 500 services, but only have one application that is the front-end? For me, that just means that you think that it's so much easier and so much smaller that it doesn't need to be cut into multiple pieces.
Lucas Dohmen: A different approach would be to say that you have let's say 10 services, but each of them produces their own HTML and delivers it to the client, and then it's basically a question of how to jump between those systems and how to integrate that, and that means that a team that works on this one system consists of both front-end and back-end developers, but they work together and they can create a system that if they want to deploy a new version, they only need to deploy that new version. Because if you compare that to the version where you have a front-end team, that has the front-end "monolith", then a change will probably also be made to the front-end and to the back-end. The teams need to coordinate that change, so they need a new field in the API, and when that field is available, then the front-end team can do something with that field, or something like that.
Lucas Dohmen: That's where I would prefer to have a cross-functional team, basically, that works together on one part of the application, that is cut into multiple pieces. Some colleagues also have that idea, and they call that kind of architecture Self Contained Systems. We can link that in the show notes. It's basically an architectural style where you cut the application not into front-end and back-end, but into different pieces.
Lucas Dohmen: I also saw customers that previously had back-ends, and then a Java desktop application, basically, and for them the jump to a client-side rendered application was conceptually much smaller, because it's the same architecture as they had before. It has advantages and disadvantages. If you say that the team just wants to keep on working the same way they did before and the back-end people can just continue working as they did before, then maybe you want to have a single-page application in the front-end that basically is that architecture... But I would argue that if you want to move from your Java application to a Web application, then you have to rethink some of the parts of your application basically, and make it more Web.
Joy Clark: When you're talking about cutting little pieces apart from each other, how do you work...? I'm thinking about user experience. Even if it's one application, I think a lot of what you probably have to do when you're developing a front-end is to think a lot about the user experience... And I can think that when we cut it into different services, then we have to think even more about the user experiences over all of the services... Could you talk about how you can do that?
Lucas Dohmen: As a company, you can basically create your own Bootstrap, your own style guide, and then tell the different teams "This is the catalog of things that you can use", and then they will look the way that the style team or design team has intended it to look. There are different approaches to how to do that.
Lucas Dohmen: If I have version 1.3 now, then I can choose to update tomorrow, and the other team can choose to update today, because they have time. Of course, you need to make sure that the versions don't split apart too much, because if one of the systems uses version one and the other one uses seven, then they will look very different, and the look and feel will not be the same... But it should be okay that one of the teams updates today and the other team updates in one week, for example, because they have an important deadline they need to meet.
Lucas Dohmen: This is possible in both the NPM version, because you can just release a new version of the package, but it's also possible in the central asset version, because you can just have a different URL for different versions of the file, and then the design UX team tells everyone "Okay, there's a new version available. You can now update to the new package."
Joy Clark: What's the relationship between front-end development and design?
Lucas Dohmen: It's a very close relationship. When I started with front-end development, I worked at a company where we had a designer, and she designed in Photoshop and sent me the Photoshop files, and then I sat down and wrote the HTML and CSS to make it look like the Photoshop file. That worked pretty well back then, and there was a clear cut, because I didn't do any design, and she didn't write any code.
Lucas Dohmen: This becomes harder and harder all the time, because nowadays we don't design for a fixed width layout, but we design for thousands of different sizes of devices... So you would need to create different mock-ups for different sizes, therefore you need to collaborate much closer together, because the designer can no longer create a mock-up for all sizes. That would be just too much work. So you have to fill in the gaps between the version for the iPhone and the iPad, what happens on those scales.
Lucas Dohmen: Designers and front-end developers need to work much closer together nowadays, because they need to communicate about what happens in those cases between. Some people say that a designer nowadays needs to be able to write HTML and CSS. I would disagree. I would say that it helps a lot, because then you have a better understanding on how it works, but I would not say that you need to be an expert CSS coder to be a good Web designer. I still think that those are two different roles, and some people are able to fill both roles.
Lucas Dohmen: I, for example, am not a very good designer, but I can put all designer things into HTML and CSS that works very well. I think that's still possible and I think that's still necessary, because they are different skillsets. Being a good designer is a different skillset than being a good CSS developer, for example. But I think we need to work closely together to make sure that both we know the limitations, and also know the new capabilities that a browser has. So if there is a new cool CSS feature, then this could be a good inspiration to a designer, because now they see "Oh, cool, we can now do this, and I didn't know that Websites can do that, so let's bring that into our product."
Lucas Dohmen: The same thing goes for UX designers. This is also a different role, but as a front-end developer, you need to be able to talk to both designers and UX people to bring all those different parts into code and into life, and I think it makes sense to learn about graphic design, about UX as a front-end developer, but I don't think you need to be an expert to be a good front-end developer.
Joy Clark: You were talking about different browsers, and I'm thinking about performance... So what role does performance play when developing front-end applications?
Lucas Dohmen: If you as a developer always have the newest hardware, like the newest MacBook Pro and the newest iPhone X, and you only test on those devices, with the fastest internet that's available, then you might think that it's okay from the performance perspective, but maybe also test it under worse circumstances, like a slow internet connection and a five-year-old Android device.
Joy Clark: Do you have a five-year-old Android device sitting at home to check your...? When you do your testing...
Lucas Dohmen: At home I don't have that, but the last customer I worked for, we bought several telephone devices and two tablets, and we tested all our code on all those devices. I think that's necessary, because there's no way that an emulator can really make sure that this is the right performance. You cannot find that on your computer. You will need to do that on a real device, you will need to see, like "If I scroll with my thumb, is it really smooth, or is it slow?" and you can only do that on a real device; there's no other way.
Lucas Dohmen: Even if it's nice to have a service that will render your page on an Android device and on an iPhone and so on to see if there are big CSS errors, for example, where on the one device the border is missing, or something... But to get a feeling for the user experience, and especially for the performance, you need to have real devices. There's no way around that.
Joy Clark: Is there any way you can optimize when you're developing for mobile devices? Because I know that most of the browsers nowadays seem to be -- when I'm at home, I don't usually open my laptop, I just check it on my iPhone, or something like that... And I'm really annoyed when the sites don't look nice on the phone.
Lucas Dohmen: One approach that people have is the so-called mobile-first design, where they say that when you create a new Web application, first create it for the smallest device that exists, because it is always easier to add more things to your application than it is to remove things. So if you start on a 30-inch display, and you design your application for that display, and then you want to make the same page available on your iPad, then you have to throw things out, because otherwise it will be much too crammed on your device.
Lucas Dohmen: One idea that people had was to just start with the smallest device, and then go to the next device size, and maybe add something, or maybe don't; it's okay to just put things in a different position, or make them bigger, or something. Then go to the next size, and to the next size... That's the basic idea of mobile-first design. I think that's still the best approach for designing a system like that.
Lucas Dohmen: I recently saw a project where they started on the big screen, and then later wanted to make it available on phones, and it was much harder, because then they realized that certain elements just don't work on the smaller screen. They look bad, or they need to cut it in a place where it doesn't look good. So start with the smallest device.
Lucas Dohmen: Usually, the smaller devices are also slower than the bigger devices, but it's not necessarily true if you have an iPhone X and a five-year-old computer, basically... But normally, if they are approximately the same age, the smaller device will also be slower, so you can also make sure that you don't need too much performance from the device. So one approach would be to just really start with a slow telephone device, and then go to a bigger, faster device.
Joy Clark: I've also heard the term "offline-first", and I didn't know what that meant. How can a Web application be offline?
Lucas Dohmen: The bigger question is "How can it be mobile-first AND offline-first? What's first now?"
Joy Clark: Mobile-first, offline-second... Offline-first, mobile-second...
Lucas Dohmen: Yeah, maybe. I don't know. I think that this something-first naming scheme is something that people came up with a while ago, and then they continued to put everything first... Like, test-driven development means test-first, basically. I'm not a big fan of this naming scheme, but yeah... What people mean when they say offline-first is that if we have devices that are not always online, then we need to think about a way of handling the offline case.
Lucas Dohmen: For example, you have your to-do list application on your phone, and you go into the supermarket and the connection drops because there's no connection in the supermarket. And if you now cannot access your to-do list items anymore, then you cannot go shopping, right? That's bad. So you need to find a solution on how to do that. And some people said that the best solution is to start with the "I have no connection" case. So in the same way that mobile-first says that first look at the smallest device and then look at the bigger devices, offline-first says "Let's first look at the devices that have no connection, and then look at the devices that have a connection."
Lucas Dohmen: If you want to design your application in an offline-first way, then you have no other choice than to put a lot of logic into your phone, because it now needs to do something when it's offline. If you want to build an application that is offline-capable, then it could also be a server-side rendered application, because now it can for example have caching on the client side. One technology that helped with that problem is service workers.
Lucas Dohmen: One problem I have with the offline-first approach is that a lot of people think about the technology problems first, and think about the user problems later... Because if you really do offline-first, then you have a lot of synchronization errors. If we two share a to-do list, for example, and it is an offline-first application, we are both offline, and you check off an element, and I edit the element, what happens when we both go back online? Is the edited item now checked off? Is that okay? Maybe it's not, because you added "and tomatoes" to the "potato" check item, and then it's not okay to just check it off.
Lucas Dohmen: For a simple application it always seems to be very clear on what to do, but the more complex your application becomes, the bigger the write conflicts between those two offline clients become. So we need to first think with the business people and the UX people and the design people "What do we do in a case where two people do something that cannot be resolved?" In a lot of cases, you need to ask your user to resolve that conflict, because you cannot do that in an intelligent way. In some cases you maybe can do it, but I would recommend people to first -- like, before they start with their offline-first application, first start with thinking about the problem cases; what happens when two people edit the same item?
Lucas Dohmen: I feel like showing people a view-only version of something as an offline capability is very useful, because if I sit on a train and I just want to quickly look into my to-do list, I want to see the to-do list, and I just don't want to see a “you’re offline” message. But if I then want to add something to the to-do list, then maybe I need to wait until I'm online, or it can be queued on your client, for example, and sent to the server later. But that's a different kind of offline capability than really saying "I'm offline-first and the application works on the client no matter if the server exists or not."
Joy Clark: Accessibility is a huge topic nowadays... Well, I don't know if nowadays; it should have always been a huge topic. But when we're talking about Web development front-ends, we're talking about creating a Web page, and how can we really make sure that we're inclusive for all of the users who come to our Web page?
Lucas Dohmen: This is why I always try to first create something with just HTML, and really do it this progressive enhancement style. Progressive enhancement basically means we have a baseline version that will work everywhere; it will work in the oldest Internet Explorer, it will work in...
Joy Clark: Wow...
Lucas Dohmen: ...everything. Maybe not everything will work, maybe the date picker will just be a text input field, but it will work, basically. And then progressive enhancement adds layers on top of that, and improvements that make it nicer to use, that make it look beautiful, and stuff like that.
Lucas Dohmen: If you follow this approach, then you start with a very minimal HTML-only version that will probably be accessible on its own. And if you then add a layer, then you need to think about what did I change about my markup, for example, that makes it impossible to use without CSS? Or you add a hint that is only in CSS, but there is nothing in the markup that says there is an error on that field. Always think about the HTML first, because that's the most accessible thing that is in your tool belt. That's the one thing I want to say about accessibility.
Lucas Dohmen: The other thing is to just do testing, because if you have a modern device, it will probably have built-in capabilities for blind users, for example. If you have an iPhone, you can put it into a blind user mode and try out how your application works... Because that's the only way to make sure that it works. Try to use your application without the mouse. Does it work or doesn't it work? Because there are people that cannot use a mouse, because their hands are too shaky for using a mouse. They prefer to use a keyboard. Try to use your Tab key to move through your application. Does it make any sense, or are you jumping around on the page? Accessibility would be a topic for another --
Joy Clark: Yes, it is a very large topic.
Lucas Dohmen: Yes, but I can put in two suggestions of books to read about that topic into the show notes. It's an important topic also from a business perspective. A lot of people think that accessibility is something you do because you are a good person, basically, but there is also an argument if you are just a business person that doesn't care about being a nice person... Not all business people.
Joy Clark: I'm a business person who is also a good person.
Lucas Dohmen: Then still there's a case for putting a lot of effort into accessibility, because they are customers, and if they cannot use your page, you will lose customers. So I think it makes sense to put effort into doing that. And just to make it clear, if you write an application in a client-side-rendered way, you can still make it extremely accessible. You can just do that, but probably it will be a little bit harder, from my experience... But it is possible, and you should do that.
Joy Clark: What's the next big thing in front-end development which we're looking out for?
Lucas Dohmen: One thing that's happening right now is CSS Grid, which changes a lot of things about the way that we can do layouts on the Web. It makes layouts on the Web much more exciting. You can do things that didn't work before. And also, it enables us to build Websites that are really responsive... From the smallest viewport to the biggest viewport, there's a layout that works on all those devices, without writing a lot of special case code for a smaller screen, a bigger screen, and stuff like that.
Lucas Dohmen: I think it's almost impossible to describe CSS Grid in an audio format, but I would suggest to watch talks about that on YouTube, for example. I will also put something in the show notes for that, because there's a great YouTube series by Jen Simmons where she shows what you can now do with CSS that you couldn't do before. I think this is a bigger revolution than most people think, because we really can do things that didn't work before.
Joy Clark: I think we covered quite a few aspects of front-end development. My question now is "How do I go about developing a front-end application?" What tools are available? What's your usual workflow?
Lucas Dohmen: I think that it is almost scary to people, because they google for "How do I put all my CSS files into one file?" and then they see a thousand different ways on how to do that, and a thousand different tools that will do that. That makes front-end scary, in a way.
Lucas Dohmen: What I usually do is I write my CSS using SCSS, which is a language that translates to CSS; some people call it a preprocessor. It adds some nice things, like imports statements, or variables, and nesting, and stuff like that. If you want to write a bigger CSS project, I would definitely suggest that you look into SCSS, because it makes a lot of things easier.
Lucas Dohmen: There are other alternatives to that, like Stylus and other languages... I just really like SCSS, but I think Stylus is fine as well if you prefer that. One advantage that SCSS has over the other solutions is that Bootstrap is written in SCSS, so if you for example want to base your application on Bootstrap and then extend onto that, then if you use SCSS you can for example only import certain parts of Bootstrap, and basically throw away all of the things that you don't need.
Lucas Dohmen: That's something that I did in the last project, for example. We started with a lot of Bootstrap components, and did like a first draft of the Web application - how should it look - and then there were a lot of things where the client said "I want to have something different than the Bootstrap component." So we threw out the Bootstrap component, wrote our own component... But yes, the baseline of Bootstrap was still there.
Lucas Dohmen: I think that Bootstrap is a good base on which to start your CSS. It gives you a certain structure, you can have your color names and stuff like that, and that's why I mostly do Bootstrap-based design. But I don't just put in the whole CSS of Bootstrap, but I import it from my SCSS, and then I can pick and choose from Bootstrap.
Lucas Dohmen: I want to make that easier for people, that's why I started a project that we can talk about in a minute. But before that, one important part of my approach to front-end is a component-based approach. A component-based approach means that I try to cut the entire page into small pieces; in the same way we do it on the back-end basically, we just don't write everything in one file, in one class, in one function etc. but we put it into smaller pieces. Then we re-use that piece to build a bigger piece, and a bigger piece, and a bigger piece. That's the idea of component-based front-ends.
Joy Clark: So a style guide is also a tool.
Lucas Dohmen: A style guide is a tool, right. There are different tools that can help you build your style guide. Some people start with the components in the style guide and then put them into their application. Some people start with the application and then extract them to the style guide... I think that to start with a style guide has its advantages, because you start at the small component level and you can look at it in isolation, make it bigger, make it smaller, and get a feeling for that.
Lucas Dohmen: One approach to put those into categories is atomic design. Atomic design says there are very small components, and then you can use bigger components that use those small components. There's an interesting book about that called Atomic Design which explains how to do that. I would recommend looking into that, especially if you are a designer or UX person, because I think it has influence on your work as well. So if you create a design with atomic design in the back of your head, then it will probably be easier to implement for the people that later write the HTML and CSS.
Joy Clark: What's your favorite style guide? Or maybe you have more than one...
Lucas Dohmen: Do you mean a style guide, or do you mean a software to create style guides?
Joy Clark: A software to create style guides... Or if you have a favorite style guide, you can share that, too. I meant the tool, but...
Lucas Dohmen: Okay. A tool I really like for that is called Fractal. It has some weird things about it, but from all the tools I've tried so far, I like it the most. I'm not a huge Fractal fan, but I would say it's a good tool and it works pretty well.
Joy Clark: I'm really excited to ask you about this, because you developed a tool for developing asset pipelines, and I really love it.
Lucas Dohmen: Thank you.
Joy Clark: That's just me interjecting... So could you tell us a little bit about your project?
Lucas Dohmen: Then you google on Stack Overflow, then you copy some code; you don't really understand what's going on there, but you copy into your code anyways, and then you are in a mess, basically.
Joy Clark: It sounds like all asset pipelines should have been implemented like that from the beginning.
Lucas Dohmen: Yeah, I don't know...
Joy Clark: Well, I think that's all of the questions I had for you. Is there anything else you would like to say about Web development?
Lucas Dohmen: I think that if you are a back-end developer that never did front-end, try it out. Try to read about CSS architecture, for example, and not just complain about it or talk about it like it's too easy to be relevant to a "real developer." I really hate the term "real developer", because I think all developers are real developers. Just try it out, and don't just think that CSS can never be maintainable. I think that's wrong. You can do that in a good way, but you need to pay the same attention to that as you pay to your back-end code. Because if you would just write your Java code like some people write their CSS code, it would also not be maintainable.
Joy Clark: Oh, I have bad pictures in my head right now...
Lucas Dohmen: Yes, that would be my conclusion, basically.
Joy Clark: You mentioned a couple of books during the podcast, and resources - we'll definitely link those in the show notes. Are there any other books or resources that you'd like to recommend?
Lucas Dohmen: Yes, there's a really good online book called Resilient Web Design. It's a little bit like a history of the Web, but also a lot of philosophy of the Web, like "How do we write applications that work very well in all browsers?" I would recommend that; it's free online, so we will link that. And there are a lot of good books from A Book Apart. They write books about CSS, design, user experience and stuff like that. I read multiple books from A Book Apart, and all of them were very good, so I can recommend that as well.
Joy Clark: Well, thank you very much for your time.
Lucas Dohmen: Thank you!
Joy Clark: To all our listeners, until next time!